Techniques and System for Specifying Policies Using Abstractions

ABSTRACT

A policy language for an information management system allows specifying or more policies using policy abstractions. The policies and policy abstractions are decoupled from one another, so policies and policy abstractions may be specified and altered separately from each other. A policy may refer to any number of policy abstractions. Multiple policies may reference a single policy abstraction, and a change to that policy abstraction will result in multiple policies being changed. Further, policy abstractions may be nested, so one policy abstraction may reference another policy abstraction, and so forth.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 11/615,477, filed Dec. 22, 2006, issued as U.S. Pat. No.9,384,360 on Jul. 5, 2016, which claims the benefit of U.S. patentapplications 60/755,019 and 60/766,036, filed Dec. 29, 2005; 60/743,121,filed Jan. 11, 2006; 60/821,050, filed Aug. 1, 2006; and 60/870,195,filed Dec. 15, 2006. U.S. patent application Ser. No. 11/615,477 is alsoa continuation in part of U.S. patent application Ser. No. 11/383,159,filed May 12, 2006, issued as U.S. Pat. No. 8,627,490 on Jan. 7, 2014;Ser. No. 11/383,161, filed May 12, 2006, issued as U.S. Pat. No.8,621,549 on Dec. 31, 2013; and Ser. No. 11/383,164, filed May 12, 2006.These applications are incorporated by reference along with all otherreferences cited in this application.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by any one of the patentdocument or the patent disclosure, as it appears in the U.S. Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates to field of information and documentmanagement, and more specifically, a policy language system for managinginformation.

Networked computer systems have evolved over the years from simpleserially connected computer systems to massively networked computersystems connected via large internal networks, intranets, and theInternet. During this evolution, many different concepts were developedto manage how users are granted access to electronic information storedin the computer systems. How a computer system determines if a user oran application has permission to access information (such as a file) hasbeen a complex problem to solve.

Some operating systems use a simple approach to determining whether auser has permission to access a file. For example the Unix® operatingsystem gives the system administrator or file owner the ability toattach access permissions to directories and files. Unix is a trademarkof the Open Group. There are three types of access permissions that thesystem administrator or file owner can select from. The permissions are:read, write, and execute. These permissions can then be limited to threetypes of users: the owner of the file, the group that the owner belongsto, and other users. Each permission and user type has two states:allowed or denied.

Whenever a user accesses a file, the Unix operating system first checksthe permissions set for a file against the user's type. The operatingsystem checks if the user falls into any of the three user types. If theuser is a member of any of the user types and the user type has beenspecified as allowed, then the operating system checks which of thepermissions are set as allowed. The user is then allowed to perform anyaccess that falls under an allowed permission.

This approach does not offer much flexibility to the systemadministrator. The system administrator cannot specify particular usersother than the owner or particular groups. The permissions are limitedto directories and files within the file system and do not cover nonfilesystem objects such as e-mails and Web pages. Further, the operatingsystem checks permissions for file accesses based only on user and itdoes not restrict file accesses based on application programs.

A more advanced approach that is commonly used is called access controllists (ACL). An access control list uses a language that allows thesystem administrator or file owner to set read, write, and executepermissions for specific users and groups of users for accesses tofiles. In some approaches, each set of access control lists for aparticular directory resides in a file stored in that directory. Theaccess control lists apply to files that are contained within thatdirectory.

When a user attempts to access a file in a directory, the operatingsystem loads the access control list file and reads the access controllist rules that were created by the system administrator or user. Theoperating system determines if the user is allowed to access the file byparsing the access control list rule. In other approaches, a set ofaccess control lists associated with a file is stored as one or moreextended file system attributes of the file. In another implementation,access control and auditing access control lists are stored in asecurity descriptor associated with a file or a directory.

There are many drawbacks to the access control list approach. The accesscontrol list approach applies only to files within a file system anddoes not apply to nonfile system objects such as e-mails and Web pages.The access control list support is built into the operating systemkernel and cannot be extended.

The access control list approach is not very portable because it is filesystem specific and is therefore not universal which means that not allfile systems support the same access control list and not all operatingsystems have the same interpretation of an access control list. When afile is copied from one file system to another (or from one operatingsystem to another), some of the control information may be lost due tocompatibility issues. Further, an access control list is difficult toapply to users outside of a company's file system (e.g., a customer).Finally, as with the operating system example above, an access controllist is capable of controlling file accesses by a user but is notcapable of controlling file accesses by a particular application programor at a particular time or location.

Applications such as document management systems require a user to checka document in and out of a library system. Once the document has beenchecked out, it can be distributed and modified in any manner. Thismeans that there is no control over how a document is used once thedocument leaves the document management system.

An information management system should control access by users orapplications, or a combination of these to information of the system.The information being controlled should include not only files anddocument, but also e-mails, access to Web sites, access to applications,instant messenger messages, databases, and much more. The informationmanagement system should have a flexible rule or policy language thatallows for implementing simple or relatively complex controls on manyaspects to the information. The information management system shouldalso be capable of being used to secure the information to ensureconfidentiality, to implement ethical walls, and more.

Therefore, there is a need for improved techniques and systems formanaging information of a network, where this information includesdocuments and e-mail.

BRIEF SUMMARY OF THE INVENTION

A policy language for an information management system allows specifyingone or more policies using policy abstractions. The policies and policyabstractions are decoupled from one another, so policies and policyabstractions may be specified and altered separately from each other. Apolicy may refer to any number of policy abstractions. Multiple policiesmay reference a single policy abstraction, and a change to that policyabstraction will result in multiple policies being changed. Further,policy abstractions may be nested, so one policy abstraction mayreference another policy abstraction, and so forth.

In an implementation, the invention provides a method of managinginformation including providing a number of policies or rules and anumber of abstractions, where a rule includes an expression having afirst variable, and the first variable is defined in a firstabstraction. A rule may include an optional context subexpression of therule to allow access to information during a particular time period. Asubset of the plurality of rules and abstractions relevant to a targetis determined. The subset of rules and abstractions is transferred tothe target. For the target, access to the information is controlledbased on the subset of rules and abstractions. Alternatively, for thetarget, application usage in the information is controlled based on thesubset of rules and abstractions.

The target may be a user. The target may be a device such as a desktopcomputer, notebook computer, personal digital assistant, smart phone, orother electronic computing device. When the target is a computer, thecomputer has executable code controlling access to the information basedon the subset of rule and abstraction components.

The definition of the first variable in the first abstraction includes asecond variable defined in a second abstraction. The first variable maybe an expression, such as a string, integer, floating point, character,Boolean, function (or method) call, directive (e.g., policy deploymentdirective and policy execution directive).

When the target is a user, then the determining a subset of theplurality of rules and abstractions relevant to the target may includefinding the subset of the rules and abstractions applicable to the user.When the target is a device, the determining a subset of the rules andabstractions relevant to the target may include finding the subset ofthe plurality of rules and abstractions applicable to the device.

Transferring the subset of rules and abstractions to the target mayinclude storing the subset of rules and abstractions in a memory of thetarget. This memory may be random access memory RAM, DRAM, Flash memory,nonvolatile memory or storage, hard drive storage, removable storage, orother memory or storage, or combinations of these.

For the target, controlling access to the information based on thesubset of rules and abstractions may include when the target requests anoperation of opening of a specific file, allowing the operation onlywhen there is no rule in the subset of the rules and abstractionsprohibiting the operation. For the target, controlling access to theinformation based on the subset of rules and abstractions may includewhen the target requests an operation of sending an e-mail message,allowing the operation only when there is no rule in the subset of therules and abstractions prohibiting the operation.

For the target, controlling access to the information based on thesubset of rules and abstractions may include when the target requests anoperation of sending an original e-mail message, encrypting at least aportion of the e-mail message and sending the encrypted e-mail messageinstead of the original e-mail message.

For the target, controlling access to the information based on thesubset of rules and abstractions may include when the target requests anoperation and the operation is allowed by the rules, performing one ormore tasks in addition to the operation. An additional task may includealtering a document or message which is a subject of the operation.

In an implementation, the invention is an information management systemincluding a number of rule components and a number of abstractioncomponents, where a rule component includes an expression having avariable, and the variable is defined in an abstraction component. Theresystem includes a policy server component, accessing the rule andabstraction components and a workstation component, connected to thepolicy server component. The workstation includes a code component

There is a deployment mode of operation during which the policy serverdetermines a set of rule and abstraction components relevant to theworkstation component, and transfers this set of rule and abstractioncomponents to the workstation component. There is an execution mode ofoperation during which the code component of the workstation managesaccess to information of the information management system based on theset of rule and abstraction components. The information of theinformation management system may include files, e-mail messages, webpages, discussion threads, results of database query, on-line forms,units of information stored on a server, or other data, and combinationsof these.

There may be an execution mode of operation during which the codecomponent of the workstation manages access to devices of theinformation management system based on the set of rule and abstractioncomponents. The devices may include computers, fixed disk drives,servers, personal digital assistant devices, or telephony devices, orcombinations of these.

In an implementation, the invention is a method of operating aninformation management system including providing a number of rulecomponents, each rule component having an expression with at least onevariable. A number of abstraction components are provided, where eachabstraction component is separate from the rule components. Eachabstraction component defines variables of the rule components, where afirst variable is found in two or more of the rule components. The firstvariable may be modified. Access to information of the informationmanagement system may be controlled according to two or more of the rulecomponents having the modified first variable.

At least one variable may not be defined in the plurality of rulecomponents. The variable would be defined in an abstraction component.The method may further include transferring a first rule referencing thefirst variable to a first target and a second target and after modifyingthe first variable, enforcing the first rule using the modified firstvariable at the first target and second target.

Controlling access to information of the information management systemaccording to two or more of the rule components having the modifiedfirst variable may include tracking, logging, blocking, encrypting, ornotifying, or combinations of these. When the information of theinformation management system include intellectual property or IP, thecontrolling access to information of the information management systemaccording to two or more of the rule components having the modifiedfirst variable may be replaced by controlling distribution of theintellectual property based on the rules and abstractions according totwo or more of the rule components having the modified first variable,where controlling includes tracking, logging, blocking, encrypting, ornotifying, or combinations of these. Intellectual property includesproprietary information of an organization.

In an implementation, the invention is a method of managing informationincluding providing a number of rules and a plurality of abstractions,where a rule includes an expression having a first variable, and thefirst variable is defined in a first abstraction, and the definition ofthe first variable in the first abstraction includes a second variabledefined in a second abstraction. For the target, controlling sending ofan e-mail message is based on the subset of rules and abstractions.

In an implementation, the invention is a method of managing informationincluding providing a number of rules and a plurality of abstractions,where a rule includes an expression having a variable, and the variableis defined in a first abstraction. A subset of the rules andabstractions relevant to a target is determined. The subset of rules andabstractions are associated to the target. For the target, access to theinformation is controlled based on the subset of rules and abstractions.

Determining a subset of the plurality of rules and abstractions relevantto a target may include determining a characteristic of the target andremoving a portion of at least one the rules based on the characteristicof the target. Determining a subset of the rules and abstractionsrelevant to a target includes determining a characteristic of the targetand removing a portion of at least one of the abstractions based on thecharacteristic of the target.

Determining a subset of the rules and abstractions relevant to a targetmay include removing constant subexpressions from the rules. Determininga subset of the rules and abstractions relevant to a target may includeremoving constant subexpressions from the abstractions. Thecharacteristic of the target may include at least one of a device typeof the target, a user associated with the target, a group associatedwith the target, an application executing on the target, or a capabilityof the target, or combinations of these.

In an implementation, the invention is a method of managing informationincluding providing a number of rules, where a rule includes anexpression; determining a subset of the rules relevant to a target; andfor the subset of the rules relevant to the target, evaluating at leasta portion of the expression of each rule of the subset, and removingportions of the expression not relevant to the target. Subset of rulesare associated to the target, and for the target, access to theinformation is controlled based on the subset of rules and abstractions.

Other objects, features, and advantages of the present invention willbecome apparent upon consideration of the following detailed descriptionand the accompanying drawings, in which like reference designationsrepresent like features throughout the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagram of distributed computing network connecting aserver and clients.

FIG. 2 shows a more detailed diagram of a computer system which may be aclient or server.

FIG. 3 shows a system block diagram of a computer system.

FIG. 4 shows a block diagram of a policy server that centrally managespolicies that are used by workstations and servers according to aspecific implementation of the invention.

FIG. 5 shows a block diagram of a number of workstations and documentservers with policy enforcers installed and coexist within a systemaccording to a specific implementation of the invention.

FIG. 6 shows a block diagram of minimal embodiments that utilize anumber of workstations each with policy enforcers installed or a numberof document servers each with policy enforcers installed according to aspecific implementation of the invention.

FIG. 7 shows a block diagram of internal components of a policy serveraccording to a specific implementation of the invention.

FIG. 8 shows a block diagram of the internal components of anintelligence server according to a specific implementation of theinvention.

FIG. 9 shows a block diagram of an interceptor and a consequenceapplicator in a policy enforcement point (PEP) module according to aspecific implementation of the invention.

FIG. 10 shows a block diagram of a policy enforcer that implementsinterception and enforcement functions using a PEP plug-in architectureaccording to a specific implementation of the invention.

FIG. 11 shows a block diagram of a policy enforcer installed on aworkstation that controls access to files on the workstation accordingto the invention.

FIG. 12 shows a block diagram of a policy enforcer on a workstationenforcing access control to a nonfile system object according to theinvention.

FIG. 13 shows a layer description of an implementation of a policylanguage system of the invention.

FIG. 14 shows the functional modes of an information system of theinvention.

FIG. 15 shows an example of interactions between multiple policies andmultiples policy abstractions and their interaction.

FIG. 16 shows an example of one policy and multiple policy abstractions,where one policy abstractions references other policy abstractions.

FIG. 17 shows accessing confidential document, seeking approval, withcentralized decision.

FIG. 18 shows accessing confidential document, seeking approval, withdistributed decision.

FIG. 19 shows blocking sending of a confidential document outside thecompany.

FIG. 20 shows encrypting a confidential document when copying to aremovable device.

FIG. 21 shows sending of a confidential document between users whoshould observe separation of duties.

FIG. 22 shows an example of a deployment operation to a workstation ofan information management system.

FIG. 23 shows an example of a deployment operation of rules associatedwith a user.

FIG. 24 shows an example of a push operation, pushing one set of rulesto a workstation and another set of rules to a server.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a simplified block diagram of a distributed computer network100 incorporating an embodiment of the present invention. Computernetwork 100 includes a number of client systems 113, 116, and 119, and aserver system 122 coupled to a communication network 124 via a number ofcommunication links 128. Communication network 124 provides a mechanismfor allowing the various components of distributed network 100 tocommunicate and exchange information with each other.

Communication network 124 may itself be comprised of many interconnectedcomputer systems and communication links. Communication links 128 may behardwire links, optical links, satellite or other wirelesscommunications links, wave propagation links, or any other mechanismsfor communication of information. Various communication protocols may beused to facilitate communication between the various systems shown inFIG. 1. These communication protocols may include TCP/IP, HTTPprotocols, wireless application protocol (WAP), vendor-specificprotocols, customized protocols, and others. While in one embodiment,communication network 124 is the Internet, in other embodiments,communication network 124 may be any suitable communication networkincluding a local area network (LAN), a wide area network (WAN), awireless network, a intranet, a private network, a public network, aswitched network, and combinations of these, and the like.

Distributed computer network 100 in FIG. 1 is merely illustrative of anembodiment incorporating the present invention and does not limit thescope of the invention as recited in the claims. One of ordinary skillin the art would recognize other variations, modifications, andalternatives. For example, more than one server system 122 may beconnected to communication network 124. As another example, a number ofclient systems 113, 116, and 119 may be coupled to communication network124 via an access provider (not shown) or via some other server system.

Client systems 113, 116, and 119 typically request information from aserver computer system which provides the information. For this reason,servers typically have more computing and storage capacity than clientsystems. However, a particular computer system may act as both as aclient or a server depending on whether the computer system isrequesting or providing information. Additionally, although theinvention has been described using a client-server environment, itshould be apparent that the invention may also be embodied in astand-alone computer system.

Server 122 is responsible for receiving information requests from clientsystems 113, 116, and 119, performing processing required to satisfy therequests, and for forwarding the results corresponding to the requestsback to the requesting client system. The processing required to satisfythe request may be performed by server 122 or may alternatively bedelegated to other servers connected to communication network 124.

Client systems 113, 116, and 119 enable users to access and queryinformation stored by server system 122. In a specific embodiment, a“web browser” application executing on a client system enables users toselect, access, retrieve, or query information stored by server system122. Examples of web browsers include the Internet Explorer browser byMicrosoft Corporation, the Firefox® browser by Mozilla Foundation, andothers.

FIG. 2 shows a more detailed diagram of a computer system which may be aclient or server. FIG. 2 shows a computer system 201 that includes amonitor 203, screen 205, cabinet 207, keyboard 209, and mouse 211. Mouse211 may have one or more buttons such as mouse buttons 213. Cabinet 207houses familiar computer components, some of which are not shown, suchas a processor, memory, mass storage devices 217, and the like. Massstorage devices 217 may include mass disk drives, floppy disks, IomegaZIP™ disks, USB removable storage, magnetic disks, fixed disks, harddisks, hard drives including both magnetic and flash storage in a singledrive unit, CD-ROMs, recordable CDs, DVDs, DVD-R, DVD-RW, HD-DVD,Blu-ray DVD, flash and other nonvolatile solid-state storage, tapestorage, reader, and other similar media, and combinations of these.

A computer-implemented or computer-executable version of the inventionmay be embodied using, stored on, or associated with computer-readablemedium. A computer-readable medium may include any medium thatparticipates in providing instructions to one or more processors forexecution. Such a medium may take many forms including, but not limitedto, nonvolatile, volatile, and transmission media. Nonvolatile mediaincludes, for example, flash memory, or optical or magnetic disks.Volatile media includes static or dynamic memory, such as cache memoryor RAM. Transmission media includes coaxial cables, copper wire, fiberoptic lines, and wires arranged in a bus. Transmission media can alsotake the form of electromagnetic, radio frequency, acoustic, or lightwaves, such as those generated during radio wave and infrared datacommunications.

For example, a binary, machine-executable version, of the software ofthe present invention may be stored or reside in RAM or cache memory, oron mass storage device 217. The source code of the software of thepresent invention may also be stored or reside on mass storage device217 (e.g., hard disk, magnetic disk, tape, or CD-ROM). As a furtherexample, code of the invention may be transmitted via wires, radiowaves, or through a network such as the Internet.

FIG. 3 shows a system block diagram of computer system 201 used toexecute the software of the present invention. As in FIG. 2, computersystem 201 includes monitor 203, keyboard 209, and mass storage devices217. Computer system 201 further includes subsystems such as centralprocessor 302, system memory 304, input/output (I/O) controller 306,display adapter 308, serial or universal serial bus (USB) port 312,network interface 318, and speaker 320. The invention may also be usedwith computer systems with additional or fewer subsystems. For example,a computer system could include more than one processor 302 (i.e., amultiprocessor system) or a system may include a cache memory. Theprocessor may be a multicore processor, such as the Intel Core 2 Duo,Intel Pentium® D, AMD Athlon™ 64 X2 Dual-Core, or Microsoft Xbox 360central processing unit (CPU).

Arrows such as 322 represent the system bus architecture of computersystem 201. However, these arrows are illustrative of anyinterconnection scheme serving to link the subsystems. For example,speaker 320 could be connected to the other subsystems through a port orhave an internal direct connection to central processor 302. Computersystem 201 shown in FIG. 2 is but an example of a computer systemsuitable for use with the present invention. Other configurations ofsubsystems suitable for use with the present invention will be readilyapparent to one of ordinary skill in the art.

Computer software products may be written in any of various suitableprogramming languages, such as C, C++, C#, Pascal, Fortran, Perl, Matlab(from MathWorks, www.mathworks.com), SAS, SPSS, JavaScript, AJAX, andJava. The computer software product may be an independent applicationwith data input and data display modules. Alternatively, the computersoftware products may be classes that may be instantiated as distributedobjects. The computer software products may also be component softwaresuch as Java Beans (from Sun Microsystems) or Enterprise Java Beans (EJBfrom Sun Microsystems). An operating system for the system may be one ofthe Microsoft Windows® family of operating systems (e.g., Windows 95,98, Me, Windows NT, Windows 2000, Windows XP, Windows Vista, Windows CE,Windows Mobile), Linux, UNIX, Sun OS, Ubuntu, or Macintosh OS X. Otheroperating systems may be used. Microsoft Windows is a trademark ofMicrosoft Corporation.

FIG. 4 shows an overall architecture of an information management systemof the invention. An embodiment of the invention centrally managespolicies or rules pertaining to the controlling of access to and usageof information including documents. Documents can be file system ornonfile system objects. For example, a file system object may be anExcel spreadsheet. A nonfile system object may be an e-mail message ordata delivered to an SAP Frontend client application (e.g., informationabout an employee) by an SAP human resource module running on a server.Some examples of disk file systems include FAT, NTFS, HFS, ext2, ext3,ISO 9660, ODS-5, and UDF.

A document may encompass objects such as a file, an e-mail message, aWeb page, an on-line report, an on-line form, a discussion thread, aresult set generated by a database query, an on-line form, a bitmap, afile system object, a data object managed by a document managementsystem, a data object managed by a content management server, a dataobject in a product lifecycle management system, a source code file or acode fragment managed by a source code management system, a data objectmanaged by a configuration management system, a data object managed by aproject management system, a data object in an enterprise resourceplanning system, a data object in a customer relationship managementsystem, a data object managed or served, or both, by a portal server, adata object served by a Web server, a data object managed or served byany application server, or any unit of information content stored usingvolatile or nonvolatile memory.

The policies allow policy enforcers (which may be called agents inspecific embodiments) to make decisions on whether to allow or denyaccess to a particular information, execute a particular applicationfunction, or operate on a particular application data object orfragment. The policy enforcers are able to perform information accesscontrol for operations resulted from user action through an applicationprogram and execution of application program logic.

Referring to FIG. 4, policies are created and managed by a policy server401. As discussed below, a policy may define to whom and under whatconditions (or conditions) access to a document is granted or denied.The policies are stored and manipulated by the policy author and policyadministrator in the policy repository 402. Policies or subsets ofpolicies, or both, are transmitted to workstations 403 and documentservers 405 to control local and remote document accesses andinformation usage.

Some examples of a workstation include a desktop computer, laptopcomputer, personal digital assistant (PDA), smart phone, thin client(e.g., HP Consolidated Client Infrastructure client or Wyse terminal),an instance of client operating environment running on a terminal server(e.g., Microsoft Windows 2003 Terminal Services and Citrix MetaFrame), aguest operating system running on a virtual machine (e.g., VMWareWorkstation and Microsoft Virtual Server 2005), a server making documentaccess or information usage request (i.e., acting as a client in thecontext of the request), Internet kiosk, and information kiosk. Aworkstation may be any computing device and computing environment fromwhich document access or information usage request is originated.

Some examples of a document server include a file server, networkattached storage (NAS), virtual NAS device (e.g., a NAS switch devicesuch as Acopia Adaptive Resource Switch, NeoPath File Director, orRainfinity RainStorage), edge file gateway (e.g., a wide area fileservice (WAFS) device such as Cisco File Engine series appliances orTacit IShared products or Riverbed Steelhead appliances), Web server,e-mail server, document management system, content management server,portal server, or database server. A document server may be otherdocument repository.

A policy enforcer can be installed on a workstation 403 to providedocument access and information usage control at a point-of-use. Thepolicies can be stored locally on the workstation. Objectives ofimplementing point-of-use control include preventing unauthorized accessto documents anywhere on the network and preventing unauthorizedinformation usage and operation on application data or usage ofapplication functions. One may think of an aspect of point-of-use accesscontrol as building a firewall around a user.

Some details on policy enforcement are described in U.S. provisionalapplication 60/755,019, filed Dec. 29, 2005. More details on policyenforcement are described in the U.S. patent application Ser. Nos.11/383,159, 11/383,161, and 11/383,164, filed May 12, 2006. Theseapplications are incorporated by reference along with all otherreferences cited in this application.

Similarly, a policy enforcer can be installed on a document server 405(e.g., file server and e-mail server) to provide protection to thedocuments on (accessible by or managed by) the document server.Information may reside on different places of the network. For example,documents or information may reside on disk arrays in a separate serverenclosure that is physically separate from a document server. Inparticular, direct attached storage (DAS) has multiple disk arrays andstorage area network (SAN) has file server volumes that are virtualized.An objective of implementing server-based protection is to preventunauthorized access to documents in a particular repository (or on aserver) from any computer on a network. In other words, one may think ofthis aspect of the invention as building a firewall around a server.Besides, an application server policy enforcer such as MicrosoftExchange policy enforcer can also control usage of application data andapplication functions (e.g., copying an e-mail message, deleting acontact and modifying a calendar entry).

The control and protection functions can be achieved either through onepolicy or multiple policies defined centrally. The policy server 401 isan intelligent system that has the ability to decide if a single ormultiple policies or subset of policies are applicable to each policyenforcer. At least a subset of all policies defined is distributed toeach policy enforcer.

Controlling document access can have different meanings when operatingon different document types. For example, if a document type is a file,then document accesses are file accesses that includes: opening/readinga file, reading a file when connected using VPN, opening a file at aparticular time of a day, writing/saving a file, deleting a file,reading a file's permission (or security setting), changing a file'spermission, reading a file's attribute, or changing a file's attribute.Another example is when a document type is an e-mail message on a mailserver then document access refers to application program internaloperations that can include: opening an e-mail, deleting an e-mail,reading an e-mail's attribute, or changing an e-mail's attribute.

Controlling information usage can have different meanings when appliedto different applications. For example, if an application is wordprocessing software, then information usage includes creating a file,opening a file, saving a file, saving a document as a different file,exporting or converting a file to a different format, printing a file,sending a file to a recipient via e-mail, publishing a file in a sharedfolder, cutting data to clipboard, pasting data from clipboard,performing drag-and-drop operation, adding macro or script to adocument, or modifying macro or script in a document. In another examplewhere an application is mail client software, information usage includescreating an e-mail, opening an e-mail, copying an e-mail, moving ane-mail, archiving an e-mail, saving an e-mail into a file, deleting ane-mail, sending an e-mail, forward an e-mail, attaching a file to ane-mail, cutting data to clipboard, pasting data from clipboard,performing drag-and-drop operation, or changing e-mail attributes.

In yet another example, if an application is an enterprise resourceplanning (ERP) application, information usage includes: creating aquote, converting a quote to an order, viewing customer information,viewing an order, viewing product pricing and discounts, viewing salesdata, viewing reports, or viewing employee information.

To control document access and information usage, a policy enforcer maycontrol user interface elements such as visual and input elements of anapplication program, commands and functionalities of an applicationprogram, and information presented to a user. For example, a visualelement of an application program includes any of: a menu, a menu item,a button, a list box, a list item, a check box, a tab, a scroll bar, aslider, an icon, an image or a hypertext link. An input element of anapplication program includes any of: a key event handler, a mouse eventhandler, or any event handler associated with a visual element.

An application program may support a large number of commands. A commandcan be invoked by selecting a menu item, pressing a button (shown on ascreen), pressing one or more keys, or pressing one or more mousebuttons. A command can also be invoked by a macro or script, or invokedby a code module that calls a function (or method) in an applicationprogram interface (API) library. For example, a command can perform atask such as opening a file, sending an e-mail message, editing a cellin a spreadsheet, editing a macro, changing text format, or more.

A function of an application program generally maps to a function ormethod in a high level programming language. For example, a function inan application program may correspond to a command such as saving afile, sending an e-mail message, or editing a cell formula in aspreadsheet. A function may also represent an internal applicationprogram operation such as a call to operating system library functionfopen( ).

If information to be displayed contains personal information such as asocial security number, personal identification number (PIN) or accountbalance, then controlling information usage includes: filtering out orobscuring the personal information.

If information to be displayed contains actionable data or objects suchas a button, a hypertext link, or a clickable image, then controllinginformation usage includes: disabling the button, removing the hypertextlink, or removing the link associated with the image.

In addition to providing control or protection, a policy enforcer canalso perform obligation and remediation operations (described furtherbelow) as a result of a document access or information usage attempt(whether successful or not) as dictated by an active policy or policies.Obligation refers to tasks related to an action that a policy engine iscurrently processing and that the policy engine is obliged to completesuch tasks. Remediation refers to tasks not directly related to anaction that a policy engine is currently processing and that the policyengine ought to carry out.

Different levels of control and protection are achieved by distributingpolicy enforcers to workstations or document servers, or both. Forexample, by using workstation policy enforcers only, such as onworkstation 403, one can achieve document access and information usagecontrol that covers access to documents on local disks 404 (i.e., localfiles), access to documents on a protected document server 405 (i.e.,protected by document server policy enforcer), and access to documentson an unprotected document server 406.

In an implementation where only document server policy enforcers areused, such as document server 405, one can achieve document accessprotection and information usage control for documents on protectedservers. The documents are accessed from workstations with a workstationpolicy enforcer installed 403 and workstations without a workstationpolicy enforcer installed 407.

When both workstation policy enforcers and document server policyenforcers are installed, the combined benefit of both installations asdescribed above will be obtained.

The policy server 401 allows policies to be centrally managed andautomatically distributed and updated to policy enforcers. In a specificembodiment, policies are not tied to (or stored with) documents. Thepolicies are evaluated when an action is taken by a user (or anapplication) to access a document. The action is intercepted andrelevant policies are applied before the action is allowed to be carriedout.

There are reaction policies and maintenance policies. A reaction policyis a policy which is triggered by an action such as a user opening afile or sending an e-mail. A maintenance policy is a policy which istriggered by a scheduler, such as a program that causes the maintenancepolicy to execute at a certain time, such as daily, weekly, or monthly,upon another nonaction event, or triggered by (or invoked by) a reactionpolicy. Implementations of the invention may include reaction policiesor maintenance policies, or both.

The policies that a policy enforcer can handle may be defined based onthe type of action, user, user group, user attribute (e.g., department,role, project or status (e.g., full-time, part-time, or consultant),user's business function), e-mail address, mailing list, host, group ofcomputers (e.g., finance department computers), type of computer (e.g.,laptop and smart phone), application program (e.g., Word, Excel,PowerPoint, FrontPage, Access, Visio, Outlook, or Internet Explorer),type of application program (e.g., word processor, spreadsheet,database, or browser), application module (e.g., SAP CRM module orOracle Finance accounting module), location (e.g., New York officeversus London office), connectivity (including access mechanism andbandwidth; e.g., LAN, WLAN, VPN, Bluetooth, Internet, DSL, ISDN, dialup,remote desktop protocol (RDP), virtual network computing (VNC) protocol,latency, secure point-to-point, 56k, broadband, 100 megabit per second,and 1 gigabit per second), time of day, day of the week, file path, filename, document size, document timestamp, document owner, documentproperties, document type (e.g., file or e-mail), document format (e.g.,XLS, PDF, or HTML format), document identifier, document classification(e.g., confidential document or financial report), documentcharacteristics (e.g., contains a watermark), document content (e.g.,contains social security number), database query, database query resultset, database query result set properties, metadata, and more. Not allof these parameters are required. A policy enforcer can interpret anyone or combination of these parameters.

Referring to FIG. 5, a more complex embodiment is shown where both anumber of workstations 515 and document servers 517 have policyenforcers 516 and 518 installed and coexist within the system. Theinteraction between a policy builder 501, policy server 506, and policyrepository 507 will be described further below.

A reporting and analysis module 502 acts as a user interface to anintelligence server 510 for displaying reports and results from dataanalysis functions. A reporting module 503 allows policy author andpolicy administrator to query and view document access activity,information usage activity and policy enforcement activity. An analysistool 504 interacts with the intelligence server 510 to perform dataanalysis which includes trend analysis, resource utilization analysis,workforce productivity analysis, analyze effectiveness of policies,event correlation, anomaly detection, signature (or pattern) detection,threshold violation detection, detect information misuse, or frauddetection. Policy author and policy administrator can use thecapabilities offered by the reporting and analysis module 502 to analyzeeffectiveness of a policy, analyze document access and information usageactivity on a document or on a server, analyze policy enforcementactivity, investigate cases of potential information misuse, detectinformation fraud, identify potential workforce productivityimprovement, optimize resource utilization, or forecast resourcerequirement. Intelligence server 510 provides functions including (i)log services, (ii) integrate with external data sources, and (iii) dataanalysis.

A log and intelligence repository 511 is used by intelligence server 510to store log data coming from policy enforcers 516 and 518, data fromexternal sources that support event correlation and data analysis, anddata generated by data analysis services. Log and intelligencerepository 511 is normally implemented as one or more relationaldatabases or sets of log files.

A lightweight directory access protocol (LDAP) server 508 and LDAPrepository 509 provide user, user group, and host information to thepolicy server to assist in composing policy and assembling policysubsets and provide information to intelligence server to support reportgeneration and data analysis. Note that LDAP servers are typicallydeployed in organizations to provide authentication service and are notcritical for the operation of the embodiment.

A management server 512 is responsible for system configuration (notpolicy configuration), system health monitoring, and system control. Itprovides centralized management of all the components in the system. Themanagement server provides a single location to view system status,modify system configurations, and manage policy author and policyadministrator user accounts. A management console 505 is a userinterface for system management via the management server.

The management server provides services such as monitoring other systemcomponents including policy servers, intelligence servers, communicationservers and policy enforcers; displaying the status of each component;registering new policy enforcers and maintaining a registry of allpolicy enforcers; managing the configuration for all servers; andmanaging configuration profiles for policy enforcers.

A communication server 514 is responsible for directing traffic amongthe policy server, intelligence server, management server, and policyenforcers. The communication server brokers communications betweenpolicy enforcers and other servers, including distribution ofconfiguration profiles, policy deployments, and the transfer of log datato the intelligence server. The communication server provides a scalablecommunication service such that the system can support a large number ofworkstations and document servers.

Referring to FIG. 6, minimal embodiments are shown that utilize a numberof workstations 610, each with policy enforcers 611 installed, or anumber of document servers 612, each with policy enforcers 613installed. An authoring and administration module 601 is a clientapplication miming on a workstation. It provides the user interface tocreate, test, publish, modify, delete, or deploy policies, or anycombination of these, manage system configuration, monitor system healthand view document access activity, information usage activity and policyenforcement activity. The authoring and administration module 601 isconnected to a control center 605. The control center is responsible forpolicy life cycle management, system management, and log datamanagement, and maintains a central policy and log repository 609.

A policy builder 602 acts as an interface to the policy server 606 andmakes it simpler for policy author and policy administrator to create,test, publish, and deploy policy rule statements. The main tasks thatcan be performed with policy builder 602 are policy authoring and policyadministration. Policy authoring functions include creating policy,modifying policy, testing policy, publishing policy (making new policyavailable for deployment and policy modifications available forredeployment) and retiring policy. Policy administration functionsinclude maintaining policy related configurations and deploying policiesto policy enforcers.

A management console 603 acts as an interface to management server 607and is a user interface for managing system configuration and health ofthe system.

A policy server 606 transfers policies to the policy enforcers 611 and613. The policy server 606 determines what policies are to be deliveredto the policy enforcers and when policies are to be updated on thepolicy enforcers. The policy enforcers report status logs such as whatdocuments were accessed or application program functions were used, andby whom (described below) and what enforcement actions have been takento the log server 608.

In a specific implementation, a policy server deploys policies todevices that make policy decisions. These devices typically have one ormore policy engines. A policy engine may be a component of a policyenforcer, policy decision server, or policy simulator.

A reporting module 604 is a user interface element that interacts withthe log server to provide report generation and data analysis functions.Policy author and policy administrator can use the reporting module toview document access activity, information usage activity and policyenforcement activity and investigate cases of potential informationmisuse, understand the effectiveness of a policy, detect informationfraud, identify potential workforce productivity improvement, optimizeresource utilization, or forecast resource requirement.

Referring to FIG. 7, the internal components of the policy server 701are shown. The policy server is responsible for policy management,including policy authoring, lifecycle, and deployment. The policy servermaintains a policy repository, 402 and 507, for storing policies. Asystem typically has at least one policy server and can contain multiplepolicy servers in order to support a large number of policy builders 501and policy enforcers 516 and 518. The policy server provides thefollowing functions: policy authoring, policy access control, policylifecycle management, policy management and policy deployment.

Policy authors and policy administrators access the policy serverthrough the policy builder application 501 which provides in a specificimplementation, a graphical user interface to author policies and managethe policy lifecycle from creation through retirement. Authored policiesare stored in a central policy repository.

A policy lifecycle module 702 provides policy lifecycle support thatcovers policy development, deployment, and management. For example,policy development uses information about users, user groups, roles ofusers, user's business functions, recipients, actions, hosts,applications and document resources being supported to compose or updatea policy. An environment is also provided to support editing(composition), staging (testing), and deployment of policies.

A policy engine 703 (or policy decision point) is responsible for policyevaluation (or execution). It helps validate a policy and it is part ofthe staging environment. Additionally, the policy engine can be setup tosupport proxy policy evaluation. A proxy policy evaluation request maybe generated by a policy enforcer under two situations:

(1) A workstation policy enforcer 516 (or document server policyenforcer 518) does not have a policy engine. A policy engine proxy inthe policy enforcer relays policy evaluation requests from policyenforcers to a remote policy engine 703 in a policy server 701 thatoffers policy evaluation services.

(2) A workstation policy enforcer 516 (or document server policyenforcer 518) does have a policy engine, but the local policy enginedecides that the local policy subset is not sufficient to make a policydecision and should delegate policy evaluation to a policy engine thathas access to wider policy scope, or access to relevant data. A proxypolicy evaluation request is made by a local policy engine to a remotepolicy engine 703 in the policy server 701 to complete the policyevaluation.

A policy optimizer 704 will optimize the run-time performance ofpolicies. The policy optimize can optimize policies prior to deployingto a policy enforcer. A policy optimizer is not necessary for operationof a minimal system, and some implementations of the invention will notinclude a policy optimizer. However, when a policy optimizer isincluded, the performance of the system will be enhanced. Morespecifically, the policies may be reduced in size, thus take lessmemory, and may also execute faster. More details on optimization arediscussed below.

Typically a policy optimizer performs one or more of the followingoptimizations: (1) common subexpression elimination, (2) constantfolding, (3) constant propagation, (4) comparison optimization, (5) deadcode or subexpression removal, or (6) redundant policy elimination.These will be discussed in more detail below.

A policy deployment module 705 handles the deployment of policies topolicy enforcers, policy decision servers (not shown), and a locationwhere a policy engine resides. During policy deployment, the policydeployment module may invoke policy optimizer 704 to optimize a set ofpolices. The set of policies can be a full set or subset of policies onthe policy server. The deployment function may be initiated by a policyserver (which may be referred to as a push operation) or a policyenforcer or target (which may be referred to as a pull operation). Ineither operational mode, a full set or subset of policies or a set ofdifferences may be transmitted to a target.

In a policy system architecture that distributes full sets of policiesto all policy enforcers, the policy deployment module takes a completeset of policies and sends it to a policy enforcer. In a policy systemarchitecture that organizes policies based on one or more specificpolicy enforcers or policies targets, the policy deployment modulereceives or locates a policy enforcer's information and delivers the setof policies or a set of differences relevant to that policy enforcer.

In a further implementation, the policy deployment module can deploypolicies in different forms depending on the capability of policy engineat the target. For example, the set of polices that is transmitted fromthe policy server to a policy enforcer (or target) may take one of thefollowing forms: (1) ASCII text, (2) binary (e.g., code or data), (3)XML (e.g., in Extensible Access Control Markup Language—XACML format),or (4) translated or compiled including policies represented in binaryform, polices translated into tables (in binary or text form) orpolicies translated into programming language (such as XML, Java, C#,Perl, or Python in source code format or compiled binaries), or acombination of these. C# is an object-oriented programming languagedeveloped by Microsoft as part of their .NET initiative. C# is based onC++ and Java.

In a specific implementation, the deployment module can translate a setof policies and policy abstractions in one policy language to anotherpolicy language. For example, an information management policy can betransformed into one or more firewall policies for a target that is afirewall device.

FIG. 8 shows the internal components of the intelligence server 801. Theintelligence server provides summary and trend analysis, signature (orpattern), anomaly, and threshold detection on document access activity,information usage activity, and policy enforcement activity. Theintelligence server is accessed using the reporting and analysis 502software tool that allows business users to create graphical reports todemonstrate compliance, understand information usage, investigate casesof information misuse, understand the effectiveness of a policy, detectinformation fraud, identify potential workforce productivityimprovement, optimize resource utilization, forecast resourcerequirement, or combinations of these. The intelligence server analyzescomprehensive log data captured in a centralized repository, which willprovide insight and accountability for information handling Policyauthors can use data captured by the intelligence server to analyze theeffectiveness of a policy. Policy enforcers can utilize the log data andinformation derived from the log data to support policy evaluation.

The log services module 802 is responsible for collecting and managinglog data coming from the policy enforcers. Log data is normallygenerated or collected by a policy enforcer or a policy engine orexplicitly by a policy via a log handler (an obligation handler) in apolicy enforcer.

The integration services module 803 is responsible for capturing eventsoccur outside the system and provide access to an external data sourceswhen needed. It may collect data produced by other application programsoutside of the system or import data stored outside the system into alog and intelligence repository 309. The integration services module canalso export log and analysis data to application program or repositoryoutside of the system. It allows the data analysis module 805 tocorrelate document access activities, information usage activities andpolicy enforcement activities with events occur external to the system.

The reporting module 804 is responsible for providing support to thereporting and analysis tool 502. Its main function is report generation.

The data analysis module 805 provides data analysis functions such asevent (or log) correlation. For example, one of the functions of theevent correlation engine in the data analysis module is to correlateseparate events that occur within a policy enforcer or across multiplepolicy enforcers to identify trends, repetitions, fraud, hackingattempts and other attacks, bad policy designs, or bad practices byusers. The data analysis module can provide several types of analysesincluding:

(1) Summary Analysis—document access activity, information usageactivity or policy enforcement activity summarized by user, document,host, policy, location, time (e.g., day or week), organization, andmore.

(2) Trend Analysis—document access activity, information usage activity,or policy enforcement activity for a given period of time.

(3) Detailed Event Forensics—detailed listing of activities for specificuser actions or policy enforcement actions. Detailed reports showingevent-level details for document access activity, information usageactivity, or policy enforcement activity.

Compliance officers can use event forensics to investigate specificincidents of information misuse. Information security officers can useevent forensics to detect information fraud, hacking attempts,unauthorized access to information, change in a user's information usagebehavior, change in a group of users' information usage behavior, oranomaly using a reference activity profile. For an informationtechnology (IT) manager, event forensics can be used to understandresource utilization, determine how many software licenses are beingused, determine how to allocate training and support resources based onactual information usage, or identify areas of potential productivityimprovement.

A policy enforcer provides three functions: interception (or detection),decision, and enforcement.

Interception refers to a function of detecting certain operations (e.g.,carried out through altering normal code execution that implements theoperation) in an existing application program or operating system toallow the operations to be examined by a policy enforcer before theoperation is carried out. Alternatively, interception may refer to afunction in an application program or operating system (e.g., the logicis implemented at development time) where the function affectsexamination of an operation by a policy enforcer before the operation iscarried out. For example, the function in an application program is aprocedure call to a policy enforcer application program interface (API)library.

Decision refers to a process of evaluating zero or more policies (orrules) relevant to an intercepted (or detected) operation and determineif the operation should be carried out, and if additional actions needto be performed.

The enforcement function is responsible for implementing the outcome(sometimes called a policy effect) produced by the decision function.For example, if a policy effect is DENY, an operation is blocked.

Interception and enforcement are normally functions of a policyenforcement point (PEP) and decision is a function of a policy engine(described further below). Both PEP and policy engine are components ofa policy enforcer. In addition, a policy enforcer can carry out audit(or log) function, and obligation and remediation tasks (describedbelow).

There can be at least two types of policy enforcers that can exist in asystem in order to provide a multilayer approach to information controland compliance enforcement: document server policy enforcers andworkstation policy enforcers. Document server policy enforcers aredesigned to control access to and usage of documents (or information) ondocument servers. While workstation policy enforcers are designed tocontrol end-user access to and usage of documents (or information) onworkstations and document servers and information usage by end-users ata workstation. Combining both types of policy enforcers in an embodimentprovides control over document access from a workstation controlled by apolicy enforcer, from a workstation not controlled by a policy enforcer,to a document server controlled by a policy enforcer, and to a documentserver not controlled by a policy enforcer, and control the usage ofinformation by organization personnel.

Policy enforcers are responsible for both enforcing policy andcollecting audit information (document access activities, informationusage activities and policy enforcement activities) for their respectivehost systems. The policy enforcers intercept end-user or system events(or actions) or information usage (e.g., invoking a function in anapplication program and operating on data in an application) that may besubject to document access or information usage control policies. Thecontext of each of these events is provided by a PEP to a policy enginewhich is responsible for evaluating policies relevant to the context.The consequence determined by policy evaluation is communicated back tothe PEP, which contains application-specific or system-specific logic tocarry out the enforcement function. If the policy evaluation results inthe requested event being denied, the PEP typically terminates therequest and returns an error status that indicates access is denied orthe requested action cannot be performed.

Since policy enforcers have access to information regarding documentaccess and information usage, such activity information (or auditinformation) can be logged by a policy enforcer to a local or centraldatabase. The activity data collected by one or more policy enforcerscan be correlated, analyzed, and applied to many applications including:(1) auditing or compliance; (2) investigation; (3) detecting informationfraud; (4) detecting information misuse; (5) detecting anomalies; (6)understanding and optimizing resource utilization; and (7) understandingand improving workforce productivity.

Document server policy enforcers are server (e.g., file server) orserver application program (e.g., mail server) specific policyenforcers. For example, a file server policy enforcer (discussed below)is designed to protect file resources on (or accessible by or managedby) the file server. In a different example, an e-mail server policyenforcer such as Microsoft Exchange Server policy enforcer controlsaccess to and usage of e-mail and other Microsoft Exchange Serverapplication objects on the server. In another example, a documentmanagement system (DMS) policy enforcer controls access to and usage ofdocuments stored in a DMS repository and other DMS specific applicationobjects.

Document server policy enforcer is installed on a server computer (e.g.,file server) or on the computer where a server application program(e.g., mail server) is installed. Alternatively, some policy enforcerfunctions including policy engine can be distributed to a separatecomputer. The interception function carried out by a PEP is server andserver application program specific and can occur inside a serverapplication program or at operating system level.

A file server policy enforcer is a type of document server policyenforcer. The file server policy enforcer controls access to and use of(e.g., copy or print) files on file servers. It is installed on a fileserver machine and enforces document access policies or informationusage policies, or both, as organization personnel interact with thefile server. Document access policies control whether users orapplication programs are allowed to access files and folders on (oraccessible by or managed by) a file server including: create, read,write, delete, copy, move, and rename files; create, open, encrypt,delete, and rename folders; access and change file or folder attributes;and create, access, change, rename, and delete links or shortcutsassociate with files or folders. The policy enforcers also log access tofiles and folders and information about each enforcement event.

The file server policy enforcer monitors network requests for files andalso monitors file system requests. This architecture allows the policyenforcer to evaluate policies based on the greatest amount of contextfor each request, since it can use both network-level and filesystem-level information. Certain file access operations can also beintercepted inside a server application program (e.g., a NFS server) andat operating system level.

In a specific file system implementation, both a file server policyenforcer and a workstation policy enforcer (described below) aretypically needed to provide thorough protection to the resources managedby the file system. For example, Andrew File System (AFS) uses a clientapplication program to cache file system objects on a workstation. Withonly an AFS server policy enforcer, file system objects cached on aworkstation are not protected. In that case, a workstation policyenforcer can be combined with an AFS server policy enforcer to providecomplete file system resource protection.

The file server policy enforcer is self-monitoring and self-protecting.When it is running, a user or process is not permitted to modify,delete, or access the policy enforcer system files including thebinaries, configuration files, log files, and policy files. If thepolicy enforcer is stopped unexpectedly, it is automatically restarted.

Policy enforcers can be installed on some or all file servers within anenterprise, depending on which file servers contain documents that theorganization wants to enforce document access policies or informationusage policies, or both, on. A file server policy enforcer affects onlythe file server where it is installed. Alternatively, the policy enginein a policy enforcer can run on a computer different from the serverbeing managed.

The file server policy enforcer is responsible for controlling access toand use of files stored on (or accessible by or managed by) a fileserver. It can control access to and use of files on a file server byworkstations that are controlled or not controlled by policy enforcers.

A workstation policy enforcer controls end-user usage of documents orinformation on workstations and application program functions. Thepolicy enforcer is installed on a workstation and controls access to andusage of documents or information, whether those documents orinformation are stored on the workstation or remotely. The policyenforcer detects (or intercept) document access activity, informationusage activity and application program operations for each applicationrunning on the workstation. Detection can occur inside an applicationprogram or at operating system level. For example, the enforcer may beembedded in the application program or in the operating system.

Usage policies control whether users of that workstation are allowed toperform various actions such as sending, printing, or copying documents.Usage policies can also apply to application data to, for example,control cut-and-paste, drag-and-drop, allow only a particular group ofusers to modify a particular spreadsheet formula, restrict editing of amacro or script by user, restrict editing to a specific region orportion in a document by user, restrict certain application functionsbased type of connectivity (such as VPN), restrict a particular typeedit to a document based on time, and screen capture functions tocontrol misappropriation of data in a document.

Policy enforcers also collect information about each enforcement eventfor an activity journal or report. The policy enforcer may beself-monitoring and self-protecting. In a specific implementation, whenthe policy enforcer is running, no user or process can modify, delete,or access the policy enforcer's system files, including the binaries,configuration files, log files, and policy files.

Policy enforcers can be installed on any number of workstations withinan enterprise. Each policy enforcer affects only the workstation whereit is installed. Policy enforcers may be embedded into a computingdevice like PDA (such as a Palm Zire™ or Tungsten™, Dell x50v or x51v,or HP IPAQ) or smart phone (such as a Windows Mobile-based smartphonedevice). A policy enforcer can also be installed on a terminal server(e.g., Microsoft Windows 2003 Terminal Services or Citrix MetaFrameServer) to control document access and information usage in each clientsession.

Workstation policy enforcer is responsible for document access andinformation usage at a point-of-use. It has the ability to controlaccess to and usage of documents or information stored locally on theworkstation and remotely on document servers, and the document serversmay be controlled by policy enforcers or not controlled by policyenforcers. The workstation policy enforcer can also control usage ofinformation and application program functions at a workstation.

Referring to FIGS. 9 and 10, document server and workstation policyenforcers 901 and 1001 have a similar architecture. An interceptor 906and 1006 is responsible for intercepting (or detecting) document accessand application operations (or actions), collecting information about anintercepted operation (e.g., type of action, document or documentsassociated with the action, and information about the application ormodule where interception occurred), and forwarding the data collectedto a policy engine 902 and 1002 to perform policy evaluation. Theconsequence of policy evaluation is returned by a policy engine to aconsequence applicator 907 and 1007. A consequence applicator isresponsible for applying consequence of policy evaluation which includespolicy effect and additional tasks.

FIG. 9 illustrates a design where an interceptor and a consequenceapplicator are components of a policy enforcement point (PEP) module 904and a policy enforcer includes of at least one PEP 904 and one policyengine 902.

FIG. 10 illustrates a policy enforcer 1001 that implements interceptionand enforcement functions using PEP plug-in architecture. The policyenforcer includes one PEP 1004 and at least one PEP plug-in module 1005.Both interceptor 1006 and consequence applicator 1007 are components ofa PEP plug-in module 1005.

A policy engine may run in a process separate from a policy enforcer.The policy decision process and policy enforcer can run on the samecomputer or on separate computers.

The interceptor and consequence applicators are functional entitieswhere implementation of the two functions varies from operating systemto operating system and application to application. In some cases, theinterceptor and consequence applicator functionalities are combined intoone code module. In other cases, the interceptor and consequenceapplicator reside in separate code modules.

To carry out interception and consequence application functions, theinterceptors and consequence applicators may function at applicationprogram level or operating system level. Application program levelinterceptors and consequence applicators are application programspecific code modules which can be implemented as add-ins, plug-ins,scripts, macros, libraries, or extension programs. Operating systemlevel interceptors and consequence applicators are operating systemspecific code modules that can be implemented as libraries, filters, ordevice drivers.

To control application usage, a policy enforcer effects control onapplication program operations (e.g., blocking an application programoperation) or filters results generated by the application programoperations (e.g., remove text or disable actionable object in theresult), or a combination of these. Normally options such as printing,cut and paste, e-mailing, editing are permitted by a certain applicationon all documents. However, using the control application usage aspect ofthe invention, some options may be disabled. For example, controllingapplication usage may include disabling one or more of an application'soperation such as print, cut and paste, e-mail, editing, save as, saveto, send to, search and replace, executing a macro or program (e.g.,Visual Basic for Applications or VBA program), track changes, show orreveal edits or comments, or other application operations for certaindocuments. In effect, the policy enforcer will control what operationsare permitted or not permitted by applications on particular informationfor documents, users, or other factors as discussed in this patentapplication. The policy enforcer may disable usage of some applicationsaltogether. For example, some users may not be allowed to use instantmessenger, to play certain program (e.g., games) during certain hours,and so forth.

An application may be any application or program (including built-infunctionality of an operating system or BIOS) such as a word processoror application suite (e.g., Microsoft Office, Microsoft Word,OpenOffice, Visio), e-mail program (e.g., Microsoft Outlook or Eurdora),personal information management program (e.g., Microsoft Outlook, LotusOrganizer) Web browser (e.g., Internet Explorer, Firefox, Opera,Safari), RSS reader, instant messenger (e.g., Yahoo! Messenger, AOLInstant Messenger, Windows Live Messenger, Gaim), voice chat (e.g.,Skype, Google Talk), web conferencing, text messaging program, media ormusic player such as an MP3 or video player (e.g., Windows Media player,Winamp, Musicmatch Jukebox, iTunes, RealPlayer, QuickTime, WinDVD,CyberDVD), print programs (Adobe Acrobat, CutePDF), operating systemprint screen or print to file, archiving program (e.g., Winzip, 7-zip,Winrar), picture viewer (e.g., ACDSee), utilities (e.g., NortonSystemworks, Norton Ghost, AVG Antivirus, Diskeeper defragmentation, OCRprogram, Adobe Photoshop, GIMP, FTP, PartitionMagic, Nero CD Burningsoftware), financial program (e.g., Quicken, TurboTax, Peachtree),database (Microsoft Access, Oracle), and many more. The program orprogram may be a commercially available program, shareware, abandonware,or open source software. The application may run under any operatingsystem.

Using interceptors and consequence applicators, an application programoperation is intercepted (or detected) and information about theapplication program operation is provided to a policy engine to make apolicy decision, and if the policy decision specifies an enforcementaction, the enforcement action is carried out effecting control on theapplication program operation or filtering of results generated by theapplication program operation.

A policy enforcer may use one or more methods to implement applicationusage control. The methods include: (a) blocking or altering anapplication program operating after it is invoked directly or indirectlyby a user but before the application program operation is carried out;(b) disabling or hiding a user interface element responsible forinvoking an application program operation so that a user cannot invokethe application program operation through the user interface element;and (c) removing, altering or obscuring a part or all of the resultgenerated by an application program operation making certain informationnot available to a user. Note that the user interface element describedin (b) may be an element of an application program (e.g., a menu item ora button) or an element of the result generated by an applicationprogram operation (e.g., a hypertext link, a check box, or a list box).

In a graphical user interface environment, an application programoperation may correspond to an operation associated with a userinterface element. If a user interface element is a menu item, acorresponding application program operation is an operation that will becarried out when the menu item is selected (e.g., printing a document).If a user interface element is a hypertext link (such as a clickableword or phrase on a Web page), a corresponding application programoperation is an operation that will be carried out when the hypertextlink is clicked (e.g., loading a new Web page or jumping to anotherposition on a Web page). Other common user interface elements include a:menu, button, list box, list item, check box, scroll bar, key (on thekeyboard), and mouse button. An application program operation may alsocorrespond to a command or function that is invoked by a user indirectly(e.g., through a macro or script) or by another application program.

To filter results generated by an application program operation, aconsequence applicator may alter, substitute, remove, hide or obscureone or more portions (or all) of the result to be presented to a user.The consequence applicator may also alter, substitute, remove, hide,disable or obscure one or more actionable objects or fragments of text(e.g., menu, tab, buttons, check boxes, list boxes, or hypertext links).

To control document access, a policy enforcer effects control ondocument access operations. Common document access operations include:read (or open), write (or save), execute (for binary file or script),delete, read permission (or security setting), and change permission.Many document repositories (especially document management systems)support additional document access operations.

Typically, interceptors and consequence applicators intercept (ordetect) a document access operation and information about the documentaccess operation is provided to a policy engine to make a policydecision, and if the policy decision specifies an enforcement action,the enforcement action is carried out effecting control on the documentaccess operation. Alternatively, the interceptors and consequenceapplicators may also integrate with an existing access control systemprovided by a document repository (e.g., document management system).

Interceptors and consequence applicators that control document accessare document repository dependent. They may be installed in a documentserver application program (e.g., HTTP server, IBM Lotus Notes Server,Microsoft Exchange Server, or Microsoft Sharepoint Portal Server), at anapplication program interface (e.g., MAPI, JMS, ODBC, JDBC, and OracleSQL*NET), at an application protocol interface, or act as a applicationprotocol proxy between a client and a server (e.g., HTTP, FTP, or SOAP),at file system libraries, at network file share protocol driver (e.g.,CIFS or NFS), or at file system device driver.

Some common document repositories include: file servers, mail servers,document management server, content management server, HTTP or Webservers, FTP servers, WebDAV servers, and database servers.

In one implementation of a policy enforcer, interceptors and consequenceapplications are installed in an existing application program oroperating system to implement interception (or detection) andenforcement functions. The interceptors and consequence applicators arenot native elements of the application program or operating system.

In another implementation of a policy enforcer, interceptors andconsequence applicators are native elements of an application program oroperating system. Interception and enforcement may be implementedthrough one or more calls to a policy enforcer application programinterface (API). For example, a policy enforcer API is provided in theform of a software development kit (SDK).

A workstation policy enforcer installs a number of application programinterceptors 906 and 1006 and consequence applicators 907 and 1007 tomonitor document access and information usage operations (or action)inside individual application programs and apply enforcement actions. Inaddition, a workstation policy enforcer also installs operating systeminterceptors and consequence applicators to monitor file access fromapplication programs and apply enforcement actions. The operating systeminterceptors can intercept operations from application programs that aremonitored by application program interceptors or not monitored byapplication program interceptors on the workstation.

Interceptors and consequence applicators can be setup during programinstallation time or any time in a program's life cycle. One method thatcan be used to set up an interceptor is to perform code analysis on anapplication program or library module and then modify the stored programcode. Another method that can be used to set up an interceptor isthrough code injection at program start-up time. Yet another method thatcan be used to set up an interceptor is to perform code injection afterthe program has been started. Code injection includes any method thatmodifies exiting program code or inserts new code to existing programcode to implement an additional function, or a combination of these two.The existing program code can reside in volatile or nonvolatile memory.

The consequence applicator implements the consequence or outcomeproduced by the policy engine. The consequence typically includes aneffect of policy evaluation and optionally obligation and remediationtasks (described below) to be carried out. Examples of an effect includewhether an operation should be allowed or denied; query a user forinput; evaluate another set (or sets) of policies; and call a customeffect handler (described below).

The local policy repository holds a copy of policies applicable to apolicy enforcer. Depending on the policy system architecture selected,the set of policies in the local policy repository may be a full set ofa set of policies on the policy server or a subset. The local policy maybe stored locally in a relational database, in one or more files, or inany form that convenient to the policy enforcer. By storing policies fora policy enforcer locally, a workstation policy enforcer can continue tofunction while a workstation is off-line and the policy server cannot bereached.

The custom effect handler, 908 and 1008, is a code module thatimplements custom effects and is optional in the policy enforcer.

An obligation handler, 909 and 1009, is a code module that carries outobligations supported by the policy system architecture. An obligationis a task that is related to the intercepted action that a policyenforcer is obligated to take. The tasks may include logging an actionbeing intercepted, sending a notification to an administrator regardingthe intercepted action, and archiving or encrypting the documentassociated with the intercepted action.

For example, a policy says “any e-mail sent to a patient should bemaintained in the patient record database; and the obligation action isto send (or “bcc”) a copy of the e-mail to the record managementsystem.” In this case, a policy enforcer will automatically apply theobligation action (i.e., archive) and send a copy of an e-mail to arecord management system.

In a second example, obligation can be used to implement regulatorycompliance requirements such as “all e-mail communications from anexecutive should be archived.” A policy can be written to capture allsend and forward actions on e-mail and apply an archive obligationaction automatically.

Some obligation handlers, 909 and 1009, are executed inside a policyenforcer process (e.g., the log handler) while others are implemented aspolicy enforcement point components executing inside an applicationprogram (e.g., an e-mail delete handler) or an operating system. Theobligation handler is optional in the policy enforcer.

The remediation handler, 910 and 1010, is very similar in function tothe obligation handler except it performs different functions.Remediation means additional actions taken that are different from whatis being intercepted. Such actions are introduced solely by policiesdefined to “remediate.”

The tamper resistance module, 914 and 1014, is responsible forpreventing, blocking, monitoring, and recovering from attempts todisable or alter the function of a policy enforcer. Many techniques canbe used to protect program files and configurations from modificationsand corruption. Some examples are: (1) Multiple copies of files can bemaintained and a missing or corrupted file can be restored from thebackup copies. (2) Checksums or signatures can be generated on importantfiles and stored in nonvolatile memory to enable detection of corruptedprogram and data files. (3) Access to policy enforcer program files andconfigurations can be restricted. (4) Changes to a policy enforcer'sWindows registry entries can also be monitored, blocked, andautomatically restored.

The communication and synchronization module, 913 and 1013, isresponsible for maintaining one or more connection to the policy serverand intelligence server, handling policy updates, and transferring logdata to the log and intelligence repository.

The policy scheduler, 912 and 1012, invokes maintenance policies set bythe administrator or user. A maintenance policy tells the policyscheduler when to perform an action and what the action is. For example,the policy scheduler can be given a maintenance policy that instructs itto perform a nightly scan of all e-mails and to delete any e-mails olderthan 90 days.

A maintenance policy uses the same format as a normal policy, but ratherthan being evaluated in response to an action by a user or applicationprogram, the maintenance policy is evaluated at a certain specifieddate, time, or both. The policy engine performs any specified obligationor remediation action specified in the maintenance policy.

A policy engine, 703, 902, and 1002, is an execution unit that processesand executes rules or policies. The policy engine takes the datacollected by an interceptor, historical data from prior interceptions,configuration and environment data, and applies the policy rulessupplied by the policy server to the data to produce a consequence. Aconsequence may include an effect (e.g., ALLOW, DENY, evaluate anotherpolicy, query user, or call a custom effect handler) and optionally oneor more obligation and remediation tasks. The use of historical data inpolicy evaluation is optional. As part of policy evaluation process, apolicy engine may decide that it needs to obtain input form a userbefore it can proceed with (or complete) policy evaluation. At thattime, a policy engine can invoke user interface elements to query theuser for input. For example, such input is related to classifying adocument (which produces document attribute values) that is required tocomplete policy evaluation.

Also, as part of the policy evaluation process, a policy engine maydecide that it needs to obtain document classification information inorder to complete policy evaluation. The process of obtaining documentclassification information may involve retrieving stored documentclassification data or dynamically invoking a document classificationengine to classify a document.

The policy engine optionally performs a list of obligation andremediation tasks or invokes a custom effect handler, or a combinationof these, if one is defined in a policy. An implementation of the policyengine is policy system architecture specific. Depending on what policysystem architecture is selected, the implementation of the policy enginecan vary significantly. Some examples include distributing full sets ofpolicies to policy enforcers, organizing policies based on the type ofpolicy enforcer the policies target, using policies defined in XACMLformat, or using policies defined in Blue Jungle's Compliant EnterpriseActive Control Policy Language (ACPL) format that uses a declarativeapproach to policy specification. More detailed information about theACPL language may be found in U.S. provisional application 60/870,195,filed Dec. 15, 2006, which is incorporated by reference.

The ACPL language is merely one example of a policy language of theinvention and is provided to help one more easily understand theinvention. There are many variations to a policy language according tothe invention and such a policy language is not limited to what isdescribed for the ACPL language. The invention includes features thatare not in the ACPL language implementation presented. A policy languageof the invention may include one or more features of the ACPL language.A policy language of the invention features that are not in the ACPLlanguage. A policy language of the invention may include one or morefeatures of the ACPL language in combination with features that are notin the ACPL language.

The policy deployment module 705 in this invention can support differenttypes of policy engine design, allowing the appropriate policy enginedesign to be selected for an individual device. For example, a smartphone policy enforcer may be limited by the device's computing power andmemory available. A policy engine inside the smart phone policy enforcermay be designed to execute precompiled and preoptimized polices thatexist in binary form. The policy optimization and compilation steps areperformed on the policy server before transmitting (the subset ofpolicies) to the smart phone policy enforcer. In this case, the smartphone policy enforcer receives and evaluates policies exists in binaryform which is a semantic equivalent of the original policies resided onthe policy server.

A number of design options are available to the design of policy engine703, the options include: (1) Support distribution of full sets ofpolicies to policy enforcers. (2) Support preoptimized policies at thepolicy enforcer. (3) Support policies transmitted to a policy enforcerin XACML format. (4) Support policies transmitted to a policy enforcerin Blue Jungle's ACPL format. (5) Support policies compiled into ASCIIor binary format. (6) Support policies translated into programminglanguage (e.g., XML, Java, C#, Perl, and Python in source code or binaryformat). (7) Support policies translated into lookup tables. (8) Supportpreinstalled, configurable policies and alter preinstalled polices'behavior through configuration changes. (9) Support built-in,configurable policies and alter built-in policies' behavior throughconfiguration changes.

In an implementation of a policy engine, a policy evaluation process canbe invoked by an interceptor 906 and 1006, a policy scheduler 912 and1012, an internal event generated by a policy enforcer or policy server,or an external event generated by another application program.

An internal event is similar to an intercepted user or applicationprogram action except that it is generated by a policy engine or othercomponents of a policy enforcement system. An internal event can provideadditional information relevant to the event similar to that ofintercepted action. In fact, an internal event often includes theinformation provided by an intercepted action which results in thegeneration of the internal event. An internal event may be generated asa result of a policy evaluation request or a result of an activity dataanalysis operation.

An external event is an event generated by another application programoutside of a policy enforcement system. This type of application programis typically a third party application integrated with a policyenforcement system (e.g., through a software development kit).Third-party application integration can be extremely useful because in aspecific implementation where policy enforcers are deployedcompany-wide, managing all types of information, the management systemhas access to information in a distributed environment without having togo through additional authentication and authorization processes. Forexample, a customer relationship management (CRM) application mayinstruct a policy enforcement system through an external event toarchive all documents related to a customer on the closing of anaccount. The handling of such an external event may include rolling up:files on file servers and desktop and laptop computers, e-mail messageson mail servers and all mail clients, and documents in documentmanagement systems.

The Blue Jungle ACPL is one example of a specific implementation of theinvention. However, the present invention has many aspects and animplementation of the invention may have any number of the featuresdiscussed in this patent, and not necessarily every feature described.

The policy engine can evaluate policies received from the policy serverusing the following steps:

(1) Receive data collected by an interceptor or provided by anintegrated application program module. The data collected by aninterceptor may include an action (or operation) being intercepted,information on the document or documents that are associated with theaction, information on the thread, process and application within whichthe action was taken, and other information which may be useful inpolicy evaluation. Actions such as cut-and-paste that do not necessarilyinvolve a document may also be intercepted.

(2) Inspect data provided by the interceptor or the integratedapplication program module and select policies that are applicable. Theselection may be based on type of action, who is the user, what is theapplication, and so on. In some policy system architectures, this policyselection step may not be necessary. In that case, all policies will beevaluated.

(3) Based on the policies selected and data provided by an interceptoror the integrated application program module, obtain additionalinformation that is used to complete policy evaluation. The additionalinformation may include configuration setting and environment data.

(4) Pass the selected policies and data collected through policyevaluation logic to produce a consequence (or outcome). The consequenceincludes one of the valid policy effects (e.g., ALLOW, DENY, evaluateanother set (or sets) of policies, query user and call a custom effecthandler), and perform any obligation and remediation tasks.

(5) If the policy evaluation consequence includes any obligation orremediation tasks, call the corresponding obligation or remediationhandlers to carry out the obligation tasks, remediation tasks, or both.

(6) If the policy evaluation consequence includes a custom effect, callthe corresponding custom effect handler to generate or apply an effect.

The policy engine can reside in a policy enforcer, a policy server, adedicated policy decision server, or any process or server that isassigned the policy decision function. Note that the policy engine maybe an optional module in the policy enforcer.

In an embodiment of the invention, the policy engine can evaluatepolicies received from the policy server, data provided by a schedulerassociated with a scheduled event, data associated with an internalevent generated by a policy enforcer or a policy server, or dataaccompanying an external event generated by a different applicationprogram.

In another embodiment of the invention, the policy engine detects thecurrent location of a device (e.g., a laptop computer) and evaluates aselected subset of policies received from the policy server according tothe current location. To determine the current location of a device, apolicy engine may examine an active connection to the device, whereinexamining an active connection includes examining an IP addressallocated to the device, or IP address or host name of an access pointwhere the device connects to. In an example where a company has twooffices, one in New York and another in Boston. If an access point inNew York office has a host name “AP-NY” and an access point in theBoston office has a host name “AP-B.” When a user connects a laptopcomputer to the network in the Boston office, the policy engine on thelaptop computer determines the host name of an access point as “AP-B”whereby evaluating only policies applicable to location “AP-B.”

The policy language syntax used in the following examples is based atleast partially on the ACPL language syntax. The ACPL language syntax isdescribed in U.S. provisional application 60/870,195, filed Dec. 15,2006, and is also described in this application in FIGS. 25-50 and theiraccompanying description.

In one implementation, a policy directive is used to label the locationswhere a policy is applicable. In such implementation, policies that arenot labeled are applicable to all locations. A location label may referto one or more locations. A location label may comprise of one or moreconstants or an expression.

# Policy 1 [location.access-point =“AP-NY”] FORdocument.name=“\\server1\legal\highly-confidential\*” ON OPEN BYuser=Legal DO (ALLOW AND LOG) OTHERS DENY # Policy 2[location.access-point=“AP-B”] FORdocument.name=“\\server1\legal\highly-confidential\*” ON OPEN BYuser=Legal DO DENY

The policies in the above example are prefixed with location labels. Inthis case, a location label comprises an expression (e.g.,location.access-point=“AP-B”). During policy evaluation, a policy engineevaluates the location labels of “policy 1” and “policy 2” to determineif “policy 1” or “policy 2” is relevant. Further, there may be a catchall policy that is applied when the value of “location.access-point”does not match any other policy having a location label specifying“location.access-point” as a matching criterion. For example, a catchall label may be “[location.access-point=DEFAULT].”

In another implementation, policies are grouped into policy sets and apolicy set directive is used to label the locations where a policy setis applicable. A policy set may be named or unnamed. A policy setcomprises at least one policy. A policy set may also include anotherpolicy set.

[location.access-point = “AP-NY”] PolicySet “NY-Office-Policies” { #Policy 3 FOR document.name=“\\server1\legal\highly-confidential\*” ONOPEN BY user=Legal DO (ALLOW AND LOG) OTHERS DENY # Policy 4 FORdocument.name=“*.xls” OR document.name=“*.pdf” ON PRINT BY user=FinanceDO DENY }

The two policies “policy 3” and “policy 4” in the above example aregrouped into a named policy set “NY-Office-Policies.” The policy set istagged (or prefixed) with a location label[location.access-point=“AP-NY”] making the policies in the policy setapplicable only when the label is evaluated to Boolean true.

In yet another implementation, a policy may comprise multipleexpressions (or subexpressions) each assigned a different locationlabel. Evaluating such policy includes selecting an expression (orsubexpression) associates with the location detected by a policy engine.

FOR document.name=“\\server1\legal\highly-confidential\*” ON OPEN BYuser=legal WHERE { SWITCH (location.access-point) CASE “AP-NY”connection.type = “LAN” OR (connection.type = “WLAN” ANDconnection.security = “VPN”) DEFAULT connection.security = “VPN” } DOALLOW OTHERS DENY

In the above example, two expressions (i.e., ‘connection.type=“LAN” OR(connection.type=“WLAN” AND connection.security=“VPN”)’ and‘connection.security=“VPN”’) are specified in the context component(i.e., the WHERE clause) of a policy. Each of the expressions isassigned a location label where the specific expression associates witha specific label will be evaluated when the value of“location.access-point” matches the specific label.

In another embodiment of the invention, the policy engine evaluatespolicies received from the policy server, detects the current locationof a device and applies policy consequence based on the current locationdetected. In such implementation, a policy may comprise multipleconsequence expressions (or subexpressions) each assigned a differentlocation label.

FOR document.name=“\\server1\legal\highly-confidential\*” ON OPEN BYuser=Legal DO { SWITCH (location.access-point) CASE “AP-NY” DO (ALLOWAND LOG) CASE “AP-B” DO DENY DEFAULT DO DENY } OTHERS DENY

In the above example, multiple consequence subexpressions are specifiedin a policy where each consequence subexpression is identified by alocation label (e.g., “AP-NY” or “AP-B”). The location labels arecompared with the value of “location.access-point” during policyevaluation to determine which consequence subexpression (e.g., “DO ALLOWAND LOG” or “DO DENY”) will be applied.

For the purpose of illustration, the following examples show theevaluation of only one policy in the policy evaluation step (by a policyengine). In practice, a policy engine can select one or more policiesrelevant to an intercepted action or the integrated application programmodule and the policy evaluation may involve more than one policy. Whenmore than one policy is evaluated by a policy engine in response to anintercepted action or the integrated application program module, policyconsequences in the evaluated policies should be combined to form onefinal policy consequence using one or more combining algorithms (e.g.,deny override or permit override). The final policy consequence is thenreturned to an interceptor and consequence applicator (or anauthorization process that invokes policy evaluation). This final policyconsequence typically contains a policy effect and optionally one ormore obligation tasks or remediation tasks.

FIG. 11 shows an example embodiment of a policy enforcer 1115 isinstalled on a workstation 1101 where a user's (or application's) OPENaction triggers a file operation (e.g., open( ) on a local disk file.Note that file system objects are handled differently from otherdocuments that are nonfile system objects. The policy definition is:

FOR document.name = “*.doc” ON OPEN BY user = NOT Employees DO DENY

The following describes a normal (i.e., ALLOW) execution path when auser accesses a file and the policy engine 1102 interprets, and theinterceptor and consequence applicator 1109 implements the above rule.Note that, as shown in FIGS. 9 and 10, the policy enforcer 1115 includesseveral components. For the ease of explanation, the policy enforcer isnot shown in full in the following examples. In this example, the policyengine 1102 and the interceptor and consequence applicator 1109components of the policy enforcer 1115 are described.

Step 1 (1104): A user or application program 1103 performs an action. Anaction can include opening a file, saving a file, moving a file,deleting a file, renaming a file and so forth. In this case, the actionis OPEN.

Step 2 (1105): The user or application action causes some applicationcode to be executed which results in calls to operating system librariesto manipulate a file. For action OPEN, the system call that applicationcode makes includes open( ) fopen( ) FileOpen( ), OpenFile( ), andCreateFile( ).

Step 3 (1107): The workstation policy enforcer is capable ofintercepting calls to operating system libraries. The file operationcalls (e.g., open( ) fopen( ) etc.) are intercepted. The interceptor andconsequence applicator 1109 that intercepts a system call collectsinformation about the file operation, calling application, and user, andforwards that information to the policy engine 1102 for furtherprocessing. The information collection may include the file name,directory, file path, application's process id, and program name.

Step 4 (1108): The policy engine 1102 takes the information receivedfrom the interceptor and consequence applicator 1109 and otherconfiguration and environment data, and applies relevant rulesdistributed to it by a policy server. Note that depending on what policylanguage is used, one or more rules can be relevant to a current action.The policy evaluation can result in an ALLOW, DENY, or DELEGATE policyeffect and it may also introduce obligation actions, remediationactions, or both. Delegation is when the policy engine 1102 evaluatesanother policy or another set of policies locally or remotely.

(a) An obligation action refers to additional action or actions that arerelated to the intercepted action that a workstation policy enforcer isobliged to perform when a certain condition or conditions are met. Forexample, an obligation action includes logging an action or sending anotification message to an administrator. An obligation can depend (ornot depend) on the ALLOW and DENY state.

(b) A remediation action refers to an additional action or actions thatare unrelated to the intercepted action that a workstation policyenforcer should take when a certain condition or conditions are met.Remediation actions may include deleting a copy of a backup file becauseonly one copy of a particular file is allowed or cleaning up a user'shome directory because the user's assigned privilege has changed due toa recent job change.

(c) Step 5 (1110): The policy evaluation decision (i.e., effect) isreturned to the interceptor and consequence applicator 1109 (in thiscase, the interceptor is also acting as a consequence applicator). Theinterceptor and consequence applicator 1109 takes appropriateenforcement action. In some cases, the interceptor and the consequenceapplicator can be separate code modules (e.g., when communicationbetween the Policy Engine and PEP is asynchronous). FIG. 11 shows theexecution path of an ALLOW effect. In the case where the policyevaluation effect is DENY, then steps 6 to 8 should be eliminated. Forthe action OPEN, if the effect is DENY, then the interceptor andconsequence applicator 1109 terminates the open( ) call immediately withan error status.

Step 6 (1111): The interceptor and consequence applicator 1109 forwardsthe system call made by the application code to an appropriate operatingsystem library and the normal operation is carried out.

Steps 7 to 8 (1112 and 1113): Depending on what system called is made itmay involve a file system device driver and access to physical disk1114.

FIG. 12 shows an embodiment where access control to a nonfile systemobject (e.g., e-mail) is being enforced on a workstation. The policydefinition is:

FOR message.from = Legal AND message.createDate < (TODAY−90) ON OPEN DODENY

Since a nonfile system object (or document) access is applicationspecific, interception is typically performed inside an application, atan application program interface (API), or at a communication protocolinterface, instead of being performed in operating system libraries ordevice drivers. In addition, interception of communication protocol canalso be performed using a proxy (or gateway) application that is placedbetween a client application and a server. An example of an applicationprogram interface includes Microsoft Messaging API, Oracle SQL*NET orJava Message Service (JMS). An example of a communication protocolincludes HTTP, FTP, WebDAV, SMTP, POP3, or IMAP4.

The processing steps are basically the same as illustrated in FIG. 11,except that interception and enforcement are performed differently.There are at least two methods for handling the interceptor andconsequence applicator on nonfile system objects. In the first method, apolicy enforcement point (PEP) containing the interceptor andconsequence applicator functions is built into an application program.With this approach, interceptor and consequence applicator functions areprovided as an integral part of an application program and theapplication program provides means to communicate with an externalpolicy engine.

The second method uses a PEP installed by instructing or instrumentingan existing application program to provide interceptor and consequenceapplicator functions. This second method allows application programsthat are not released with document access and information usage controlcapabilities to be retrofitted to provide such capabilities. Besidesinterceptor and consequence applicator functions, a PEP may alsoimplement obligation and remediation task handling capabilities.

Adapting an application program to provide interceptor and consequenceapplicator functionalities may include one or more instrumentationtechniques. The following are instrumentation techniques available forretrofitting application programs to provide document access andinformation usage control capabilities:

(1) Using application program interfaces (APIs) available to implementinterceptor and consequence applicator functionalities. (2) Implementinginterceptors and consequence applicators in an in-process add-on (orplug-in) module or extension library. (3) Implementing interceptors andconsequence applicators in a callback module. (4) Implementinginterceptors and consequence applicators in a device driver. (5)Performing function (or method), class (or object), library, program,and device driver wrapping either statically or dynamically so that aninterceptor has a chance to examine an application program operationbefore the actual operation is carried out. (6) Installing (orregistering) a message filter, message hook, message handler, eventfilter, event hook, event handler, preprocessing callback,post-processing callback, device driver, and device driver filter at theapplication program installation time, application startup time, orafter an application program has started up, so that an applicationprogram operation can be intercepted and examined by an interceptor. (7)Performing program code analysis and modifying application program codestatically or dynamically to install interceptors and consequenceapplicators.

Again, a workstation policy enforcer provides access control. Itcontrols what user can view, edit, send, and so forth. The workstationpolicy enforcer also addresses problems created by caching and offlineoperations. For example, Microsoft Outlook can cache e-mail messages ona client computer and a Microsoft Exchange Server policy enforcer cannotcontrol accesses to those cached e-mail messages.

The workstation policy enforcer and document server policy enforcer canindividually provide different “use” control and access protection.

In an embodiment of the invention, enforcement of document accesscontrol and information usage policies at a point-of-use can beimplemented dynamically on a workstation. This policy enforcementtechnique is sometimes referred to as dynamic point-of-use policyenforcement (DPPE) or on-demand policy enforcement.

When a user access a document on (or managed by or accessible by) aserver that is controlled by a policy enforcer from a workstation thatis not controlled by a workstation policy enforcer, the document serverpolicy enforcer can perform one of the following tasks to ensure thedocument access requested will continue to be protected.

(1) Instruct a user to access the document via a terminal server that isprotected by a policy enforcer or redirect the document access requestto a terminal server.

(2) Instruct the user to access the document through a proxy or gatewaythat is protected by a policy enforcer or redirect the document accessrequest to the proxy or gateway.

(3) Instruct the user to install a policy enforcer on the workstation orautomatically install a policy enforcer on the workstation.

(4) Instruct the user to install an application policy executive (alsoreferred to as application program policy enforcer) in an applicationprogram on the workstation that accesses the document or automaticallyinstall the application program executive in the application program.

(5) Install executable code (e.g., a script or macro) into the documentbeing requested to enable functions in an application program on theworkstation that accesses the document to control access or install oneor more code module to add access control functions to the applicationprogram. Executable code installation can be performed when the userrequest a document or executable code can be pre-installed and store onthe server.

Dynamic point-of-use policy enforcement may be implemented usingpoint-of-use policy enforcement agent (PPEA). There are three types ofpoint-of-use policy enforcement agents: policy enforcer (discussedelsewhere in this application), application policy executive, andapplication program scripting host.

An application policy executive is a program module including one ormore policy enforcement points and a policy engine, embedded inside anapplication program. An application policy executive is typicallyimplemented using ActiveX (a Microsoft Windows library), Java library,JavaScript or ECMAScript, Microsoft Windows Visual Basic for Application(VBA), or Microsoft Office macro. Some examples of application policyexecutive implementations include an ActiveX library installed in a Webbrowser (e.g., Internet Explorer or Mozilla Firefox), a Java appletinstalled in a Web browser, or a Microsoft Office add-on installed in aMicrosoft Office application (e.g., Microsoft Word, Microsoft Excel, orMicrosoft PowerPoint).

An application program scripting host is an environment for executingapplication scripts. Typically, an application program scripting host isa functionality implemented in an application program (e.g., MicrosoftOffice macro, or JavaScript support in Web browsers) or operating system(e.g., Microsoft Windows Visual Basic for Application (VBA)). In eitherimplementation, a scripting capability is available to an applicationprogram.

When dynamic point-of-use policy enforcement is implemented using policyenforcers, three implementation options are available. In option 1, apolicy enforcer can be downloaded to a workstation dynamically andinstalled on the workstation that does not have a policy enforcerinstalled when a document or information on a server having a policyenforcer that supports dynamic point-of-use policy enforcement isaccessed form the workstation. In addition, policies associate with theworkstation or the user, or both, will be deploy to the workstation. Thepolicy enforcer will be able to enforce policies on all applicationprograms and operating system.

In option 2, a document or information access request is reroute to aproxy server or gateway where policy enforcement occurs (i.e., a policyenforcer is installed on the proxy server or gateway).

In option 3, a document or information access request is rerouted to aterminal server (e.g., a Microsoft Windows Server 2005 running TerminalServices or Citrix MetaFrame) where policy enforcement occurs (i.e., apolicy enforcer is installed on the terminal server).

When dynamic point-of-use policy enforcement is implemented usingapplication policy executives, an application policy executive will bedownloaded to and installed on a point-of-use workstation when adocument or information on a server having a policy enforcer thatsupports dynamic point-of-use policy enforcement is accessed from theworkstation. In addition, policies associated with the application orthe user, or both, will be deployed to the application policy executiveto enforce document access, information usage and application operationcontrol policies associated with the application program. Theapplication policy executive will be able to enforce policies for theapplication program. In a specific implementation, the downloading andinstalling of application policy executive for an application programmay include installing application policy executives in otherapplication program on the workstation.

When dynamic point-of-use policy enforcement is implemented usingapplication program scripting host, one or more scripts or macros thatimplement policies associated with a document is injected or embeddedinto the document. The one or more scripts that implement a set ofpolicies can be translated from an original policy format (such as BlueJungle ACPL). The step of injecting or embedding one or more scripts ormacros can be performed statically or dynamically. Static injection orembedding scripts or macros into a document refers to the altering of anoriginal document and storing the altered document on nonvolatile memorysuch as a hard disk. Dynamic injection or embedding scripts or macrosinto a document refers to the altering of document when a document isaccessed and the altered document is transferred to the point-of-useworkstation. The application program scripting host technique relies ona script execution environment provided by an application to execute theinjected or embedded scripts or macros to implement the policyenforcement functions.

In an embodiment of the invention, dynamic point-of-use policyenforcement, a system includes a document server, a workstation, and aterminal server. The document server (e.g., a file server or an e-mailserver) is protected by a policy enforcer that supports dynamicpoint-of-use policy enforcement. The workstation (e.g., a laptop ordesktop) does not have a policy enforcer and it denotes a point of use.The terminal server has a policy enforcer and application programsinstalled.

In a step 1, a user logs on to the workstation and attempts to open adocument on the document server.

In a step 2, the policy enforcer on the document server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. One of the relevant policies specifies that the documentmust be protected at a point-of-use. The policy enforcer queries theworkstation for a policy enforcer and cannot find one on theworkstation. The document server policy enforcer returns a documentdifferent from the requested document to the workstation where thereturned document contains a message telling the user to log on to theterminal server to open the requested document.

In a step 3, the user logs onto the terminal server using a terminalserver client application and attempts to open the document from theterminal server.

In a step 4, the policy enforcer on the document server intercepts thedocument access request from the terminal server. Processing of therequest is similar to step 2 but the policy enforcer on the documentserver detects a policy enforcer on the terminal service satisfying therequirement specified in a policy. Opening of the requested document issuccessful.

In a step 5, the requested document is opened on the terminal server andthe policy enforcer on the terminal server controls information usage onthe opened document. Since the user uses a terminal server client toaccess the terminal server, the document is displayed on the workstationbut controlled by the terminal server policy enforcer.

In a specific implementation of step 2, the document server policyenforcer returns a document containing a macro or script thatautomatically setup a terminal server client session for the user. Inaddition, the macro or script may also cause the document to be openedon the terminal server.

In an embodiment of the invention dynamic point-of-use policyenforcement, a system includes of a document server, a workstation, apolicy server and a distribution server. The document server (e.g., afile server or a document management server) is protected by a policyenforcer that supports dynamic point-of-use policy enforcement. Theworkstation (e.g., a laptop or personal digital assistant) does not havea policy enforcer and it denotes a point of use. The policy server hasaccess to a number of rules or policy abstractions, or both. Policyenforcer software is available for download from the distributionserver.

In a step 1, a user logs on to the workstation and attempts to open afile on the document server.

In a step 2, the policy enforcer on the document server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. One of the relevant policies specifies that the documentmust be protected at a point-of-use. The document server policy enforcerqueries the workstation for a policy enforcer and cannot find one on theworkstation. The document server policy enforcer returns a documentdifferent from the requested document to the workstation where thereturned document contains a message telling the user to download andinstall a policy enforcer before reattempt to open the requesteddocument. The message may also include a hypertext link pointing to adownload Web page.

In a step 3, the user accesses the distribution server to download apolicy enforcer and installs the policy enforcer onto the workstation.In a specific implementation, a set of policies or policy abstractions,or both, is installed with the policy enforcer. In anotherimplementation, the newly installed policy enforcer contacts the policyserver (directly or via other servers) to download a set of policies forthe workstation or the user, or both.

In a step 4, with a policy enforcer running on the workstation, the userattempts to open the requested document again and the request iscompleted successfully.

In a specific implementation of step 2, the document server policyenforcer returns a document containing a macro or script that providesan interactive process to assist the user to download and install apolicy enforcer on the workstation.

In an embodiment of the invention dynamic point-of-use policyenforcement, a system includes a document server, a proxy server orgateway, and a workstation. The document server (e.g., a file server)stores documents that can be accessed from a proxy server. The proxyserver is protected by a policy enforcer that supports dynamicpoint-of-use policy enforcement. The workstation (e.g., a laptop ordesktop) denotes a point of use. In this example, the proxy server is aWeb server.

In a step 1, a user logs on to the workstation. At the workstation, theuser logs onto the proxy server using a Web browser to establish asession on the proxy server. Using the Web browser, the user opens afile on the document server.

In a step 2, the policy enforcer on the proxy server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. Using information associated with the document accessrequest (e.g., file path) and the session (e.g., user id), the policyenforcer determines if the document access should be allowed.

In a step 3, if the document access request is allowed, the document isdisplayed in the Web browser. If the document access request is denied,an error message is displayed on the Web browser.

In a specific implementation of step 2 where the document access requestis allowed, the document server policy enforcer embeds JavaScript in thereturn document to disable functions in the Web browser to implementadditional access control functions at the workstation.

In a specific implementation of step 2 where the document access requestis allowed, the document server policy enforcer triggers the uploadingof an application policy executive and a set of policies in the Webbrowser on the workstation before returning the document to the Webbrowser.

In a specific implementation, the proxy server includes an Apache HTTPServer.

In a specific implementation, the proxy server includes a MicrosoftExchange Server with Outlook Web Access support.

In an embodiment of the invention dynamic point-of-use policyenforcement, a system includes document server, a proxy server orgateway, and a workstation. The document server (e.g., a file server)stores documents that can be accessed from a proxy server. The proxyserver is protected by a policy enforcer. The workstation (e.g., alaptop or desktop) denotes a point of use. In this example, the proxyserver is a terminal server (e.g., Microsoft Windows 2003 with TerminalServices installed) and an application program on the workstation usedto access the proxy server is a terminal server access client (e.g.,Microsoft Windows XP Remote Desktop).

In a step 1, a user logs on to the workstation. At the workstation, theuser logs onto the proxy server using a terminal server access client toestablish a connection with the proxy server. Using the terminal serveraccess client, the user opens a file on the document server.

In a step 2, the policy enforcer on the proxy server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. Using information associated with the document accessrequest (e.g., file path) and the connection (e.g., user id), the policyenforcer determines if the document access should be allowed.

In a step 3, if the document access request is allowed, the document isdisplayed in the terminal server access client on the workstation. Ifthe document access request is denied, an error message is displayed onthe terminal server access client on the workstation.

In an embodiment of the invention dynamic point-of-use policyenforcement, a system includes a document server, a workstation, apolicy server, and a distribution server. The document server (e.g., afile server or Web server) is protected by a policy enforcer thatsupports dynamic point-of-use policy enforcement. The workstation (e.g.,a laptop or desktop) does not have a policy enforcer and it denotes apoint of use. The policy server has access to a number of rules orpolicy abstractions, or both. Application policy executive software isavailable for download from the distribution server.

In a step 1, a user logs on to the workstation and attempts to open afile on the document server using an application program (e.g., InternetExplorer, Mozilla Firefox, Microsoft Word, Microsoft Excel, or MicrosoftOutlook).

In a step 2, the policy enforcer on the document server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. One of the relevant policies specifies that the documentmust be protected at a point-of-use. The document server policy enforcerqueries the workstation for a policy enforcer or an application policyexecutive for the application program and cannot find one on theworkstation. The document server policy enforcer returns a documentdifferent from the requested document to the workstation where thereturned document contains executable code (e.g., a script or macro) orinstruction to redirect to a different location, or both. In a specificimplementation, the document server policy enforcer may return a messagetelling the user to download and install an application policy executivebefore reattempt to open the requested document. The message may alsoinclude a hypertext link pointing to a download Web page.

In a step 3, the user accesses the distribution server to download anapplication policy executive and install the application policyexecutive into the application program on the workstation. In a specificimplementation, a set of policies or policy abstractions, or both, isinstalled with the application policy executive. In anotherimplementation, the newly installed application policy executivecontacts the policy server (directly or via other servers) to download aset of policies for the application program or the user, or both.

In a step 4, with an application policy executive running in theapplication program, the user reattempts to open the requested documentand the request is completed successfully.

In a specific implementation of step 2, the document server policyenforcer returns a document containing a macro or script, or a Web pagethat provides an interactive process to assist the user to download andinstall an application policy executive in the application program.

In a specific implementation, the policy server and distribution servermay be one server.

In an example, the application program is Internet Explorer, thedocument requested includes a Web page and the application policyexecutive is implemented as an Internet Explorer add-in module.

In an example, the application program is Mozilla Firefox, the documentrequested includes a Web page and the application policy executive isimplemented as JavaScript.

In another example, the application program is Microsoft Word, thedocument requested includes a word processing document (e.g.,myreport.doc) and the application policy executive is implemented as aMicrosoft Office add-on module.

In an embodiment of the invention dynamic point-of-use policyenforcement, a system includes a document server and a workstation. Thedocument server (e.g., a file server, Web server or document managementserver) is protected by a policy enforcer that supports dynamicpoint-of-use policy enforcement. The workstation (e.g., a laptop ordesktop) does not have a policy enforcer and it denotes a point of use.

In a step 1, a user logs on to the workstation and attempts to open afile on the document server using an application program (e.g., InternetExplorer, Mozilla Firefox, Microsoft Word, Microsoft Excel, MicrosoftOutlook).

In a step 2, the policy enforcer on the document server intercepts thedocument access request (i.e., open) and evaluates policies relevant tothe request. One of the relevant policies specifies that the documentmust be protected at a point-of-use. The document server policy enforcerqueries the workstation for a policy enforcer or an application policyexecutive for the application program and cannot find one on theworkstation.

In a step 3, the document server policy enforcer selects a set ofpolices applicable to the document, the application program and theworkstation. For the selected set of policies, the document serverpolicy enforcer identifies an application program scripting hostsupported by the application program on the workstation, and translatesthe selected policies into a scripting language supported by theapplication program scripting host. The requested document is altered toinclude the translated script or scripts representing the selectedpolicies.

In a step 4, the document server policy enforcer returns the altereddocument to the workstation where the translated script or scripts isexecuted inside an application program scripting host to implement theselected policies.

In a specific implementation of step 3, the document server policyenforcer selects a set of policies applicable to the document form itslocal policy repository. In another implementation, the document serverpolicy enforcer requests a set of policies applicable to the documentfrom a policy server. In yet another implementation, the document serverpolicy enforcer request a script or scripts representing a set ofpolicies applicable to the document from the policy server.

In a specific implementation of step 3, the document server policyenforcer identifies an application program scripting host based on adocument type. For example, if a document is a Microsoft Word orMicrosoft Excel file, the application program scripting host isMicrosoft Windows Visual Basic for Applications (VBA). In anotherexample, if the document type is HTML, the application program scriptinghost includes a JavaScript or ECMAScript engine.

In a specific implementation of step 3 where the document server storesthe altered version of the document, the operation described in step 3is replaced by locating the altered version of the document.

In an example, the application program is Internet Explorer, thedocument requested includes a Web page or HTML document and the scriptor scripts embedded into the document to implement information usagecontrol policies is JavaScript.

In another example, the application program is Microsoft Excel, thedocument requested includes a spreadsheet (e.g., balancesheet.xls) andthe script or scripts embedded into the document to implementinformation usage control policies is Microsoft Windows Visual Basic forApplications (VBA) script.

In an example where the set of policies applicable to the documentdenies the user from printing the document, the script or macro (orscripts or macros) embedded in the document is executed when thedocument is opened in the application program on the workstation wherethe script or macro (or scripts or macros) disables all print menuitems, toolbar buttons and equivalent functions in the applicationprogram which effectively denies the user from printing the document.

In another example where the set of policies applicable to the documentdenies the user from copying the document, the script or macro (orscripts or macros) embedded in the document is executed when thedocument is opened in the application program on the workstation wherethe script or macro (or scripts or macros) disable all “Save,” “SaveAs,” “Print,” “Export,” “Send in e-mail,” “Send To,” “Copy,” “Cut,” and“Drag-and-drop” menu items, toolbar buttons, and equivalent functions inthe application program which effectively denies the user from copy thedocument or portion of document.

In yet an example where the set of policies applicable to the documentdenies the user from changing specific cell formulas in the documentwhich includes a spreadsheet, the script or macro (or scripts or macros)embedded in the document intercepts cell edit operations in theapplication program and blocks the cell edit operation when theoperation attempts to change at least one of the specific cell formulas.

A policy language for information system of the invention includespolicies and policy abstractions. Policies may also sometimes bereferred to as rules, and policy abstractions may also sometimes bereferred to as abstractions or variables. There may be any number ofpolicies or abstractions, or both. Typically, an information system willhave hundreds, thousands, millions, or greater number of rules. Becausemany rules are typically used to manage information in a companyeffectively, there should be a system to effectively managing thepolicies and policy abstractions.

In an embodiment of the invention, the policies or rules are decoupledfrom the physical resources using policy abstractions. For example, thefollowing is a policy that says legal documents can only be viewed bylegal team. “Legal-Docs” is an abstraction object which is specifiedseparately from the policy. One abstraction may apply to more than onepolicy.

FOR Legal-Docs ON OPEN BY Legal-Team DO ALLOW OTHERS DENY

For the above example, both Legal-Docs and Legal-Team are abstractionsin the policy. The exact definition of these abstractions is decoupledfrom the policy. The definition of these abstractions may be:

Legal-Docs = document.category = “contract” OR document.name =“//legal-server/cases/**” OR document.name =“//server1/departments/sales/contracts/**” OR message.from = Legal-TeamOR message.to = Legal-Team; Legal-Team = <all users in LDAP group“legal”> OR <all users in LDAP group “outside-counsel”> OR user.email =“*@outside-law-firm-1.com” OR user.email = “*@outside-law-firm-2.com”;

A further aspect of the invention is that decoupling of the rules frompolicy enforcers (or agents) where the rules or policy abstractions, orboth, are evaluated. For example, some rules are relevant to serveragents while some rules are relevant to client agents. However, user orpolicy author does not need to know where a rule is applied, theselection (or target binding) process is done automatically. This makesrules management much easier. This also makes supporting differentclients and new type of clients easier.

In an implementation, one or more policy deployment directives can bespecified in a policy to designate at least one target, target type ortarget group that the policy should be deployed or transferred to. Someexample of a target includes a “Microsoft Exchange Server,” or “ApacheHTTP Server.” A target type may include a laptop computer, personaldigital assistant, e-mail server, or instant messenger. A target groupincludes “marketing computers.” If both policy deployment directives andautomatic target binding are implemented, the combined benefit of userguided deployment and automatic deployment can be achieved.

Another aspect is that a single policy may be applied to multipledissimilar policy enforcers. This is another benefit of the decouplingtechnique of the invention.

In an embodiment of the policy language, policies are specified in atop-down manner. Top-down policy specification is a natural outcome ofpolicy abstraction. Since an abstraction decouples policy specificationfrom policy implementation (e.g., what types of files and files in whatdirectories are considered sensitive), policies can be specifiedtop-down using abstract terms. Such abstract terms can be predefined orcaptured in a policy abstraction at a later time.

In an embodiment, the policy language is declarative. This meanspolicies can be used to make declarative statement of policy withoutburdened by implementation details. The declarative aspect of the policylanguage is another benefit provided by providing abstraction.

Another aspect is the policy language may allow policies to be nested.One policy may call or delegate control to another policy. There may bemultiple levels of nesting. Further, a policy may optionally contain ascope that it belongs to. Normally scoping is determined automatically.

FIG. 13 shows a layer description of an implementation of a policylanguage system of the invention. A policy language system of theinvention may have any number of layers and the structure may behierarchical, where there are higher and lower level layers compared toother layers. In the FIG. 13 implementation, there are three layers inthe structure. There is a policy object layer 1331, abstraction objectlayer 1336, and entity object layer 1338. In this embodiment, the layersare hierarchical. The policy object layer is higher than the abstractionobject layer, which is higher than the entity object layer. Lower layersgenerally contain more specific and more physically-related informationcompared to a higher layer.

In brief, the policy object layer is a layer where policies are defined.Policies (or rules) and a specific example of a policy language arediscussed in this application. In a policy language systemimplementation, at least some of the policy objects may have a referenceto one or more abstraction objects, which is where variables in thepolicies are specified, as discussed in this application.

Some of the abstraction objects may reference one or more entityobjects. Entity objects include an entity name and a value, the valueincluding at least a reference to a physical entity. An example of areference to a physical entity, which may a user, device, file, e-mailmessage, Web page, result set of a database query, application dataobject, application program, group of users, group of devices, group offiles, or group of application programs.

A specific implementation of the layer description of a policy languagesystem of the invention is the Blue Jungle Compliant Enterprise ActiveControl System. Active Control System is built on ACPL, a flexible andextensible policy language that allows active control to be defined inbusiness terms for consistent enforcement across enterprise-wide,heterogeneous systems.

ACPL policies can refer to business entities such as “Customer PrivateInformation” or “Financial Systems,” to allow a single policy to governvirtually unlimited underlying network resources. In thisimplementation, policy objects are called ACPL policies and abstractionobjects are called policy components. Policy components are used tomodel business entities and policy functions. Business entities mayrepresent users, location, actions, document resources, applicationoperations, servers, and application programs. Policy functions mayinclude business context, policy actions, and policy obligations.Collectively, these policy components, component services, abstractionengine, component interface, and component packaging service make up apolicy component model which corresponds to the abstraction object layerof the layer description of a policy language system.

When applied to information control, a policy object (or policy) mayrepresent a statement that describes a document access or usagesituation and define what action a policy enforcer should take when thatsituation arises. In effect, a policy object represents a rule (or a setof rules) controlling how different categories of users in anorganization are allowed to use different categories of documents. Forexample, one may construct policy objects as combination of abstractionobjects that are linked together with operators and other logicalconstraints, and then further refined the policy objects by applyingcontextual conditions, such as time of the day. Typically, anorganization will construct enough policy objects to cover all potentialbusiness situations where some kind of information control is required.

In an implementation of the invention, a policy object may comprise of aset of predefined building blocks (or abstraction objects) strungtogether according to a precise syntax. Because the abstraction objectsare logical representation of specific physical entities, policy objectsconstructed based on the abstraction objects also possess greatflexibility in covering activities (or actions) and entities in thephysical network with little regard to how the activities and entitieschange and evolve over time.

In an embodiment where policy objects are applied to informationcontrol, two types of policies (or policy objects) may be defined:access policies and usage policies. The differences between the types ofpolicies are where the policies are deployed and what type of useractivity they control.

Access policies are typically deployed to servers (e.g., file servers),client computers (e.g., laptops or desktops), or both. For example, anaccess policy on a file server controls whether users are allowed tocreate, read, update, or delete documents that are stored on that fileserver. An access policy on a client computer can control whether userson that client computer are allowed to create, read, update, or deletedocuments in specified storage locations (e.g., local disks or remotefile shares). An access policy on a client computer can additionallycontrol which applications that a user can use on that client computer.Access policies are useful for controlling access to resources such asdocuments and particular file servers. To enforce what tasks users cando with documents once they access the documents, usage policies must bedeployed.

Usage policies are typically deployed to client computers. In someimplementations, usage policies may be deployed to server computers.Usage policies control whether users of that client computer are allowedto perform various application operations such as sending, printing, orcopying particular types of files.

Abstraction objects are abstract building blocks that are defined tosupport the construction of policy objects. For example, informationcontrol policies in an organization may be implemented using a set ofpolicy objects. The set of policy objects may reference one or moreabstraction objects and the abstraction objects may represent categoriesor classes of physical entities in an organization that play some rolesin information control, or the abstraction objects may representcategories or classes of actions the physical entities may perform. Forexample, abstraction objects may represent users, computers,applications, resources such as documents, or actions. Typically,abstraction objects do not represent individual real world entities butrather the logical organizations of the real world entities. Abstractionobjects provide a layer of abstraction that insulates an organization'sinformation control policies (or policy objects) from changes to theorganization's environment such as changes in physical entities.

Common changes that may occur in an organization include employees joinand leave the organization, documents being created and deleted, andservers and client computers being purchased and retired. In spite ofthese changes, by using abstraction objects in a policy, a policy authorcan write information control policies without needing to know thespecifics about the underlying physical entities (such as users,documents, or servers). In a policy enforcement system according to theinvention, relationships among information control policies and theirunderlying physical entities are resolved automatically, wherebyallowing information control polices to adapt to changes in a physicalenvironment. When changes in physical entities occur in an organization,information control policies that build on abstraction objects willremain in effect, covering all appropriate physical entities representedby the relevant abstraction objects.

In an example, a policy author may create an abstraction object thatrepresents a category “all users with the job title of Manager” torepresent all managers in an organization, rather than listing everymanager in the organization by name in a policy object. Once suchabstraction object is created, the policy author or another policyauthor may use the abstraction object as a building block to constructpolicies (or policy objects) that prevent (or allow) all managers fromusing specific information in specific ways. By allowing policy authorto construct policy objects based on abstraction objects, it meanswhoever designs policies using abstraction objects does not need anydirect knowledge of who the managers are, or who will gain or losehis/her manager title in the future. The policy author needs to knowonly the managers as a category should be denied (or allowed) access toand use the specific information.

In one aspect of the invention, a policy author may use abstractionobjects in any combination to construct policies (or policy objects) tocontrol information access, usage, or both. For example, a policy authormay define an abstraction object “Independent Contractors” to representa class of users, and an abstraction object “Copy, Move, Print, or Sendvia E-mail or IM” to represent a class of actions. Then, a policy authormay combine the abstraction objects in a policy object to define an“eye-only” rule that specifies “all independent contractors may readcompany documents but may not transmit them in any way.” Once the policyobject is distributed to policy enforcers in an organization, the policyobject (or rule) will be enforced on the operations described regardlessof which contractor and which document are involved.

A policy author may define abstraction objects based on his/herknowledge of the physical entities and other entities in an organizationregardless of how the abstraction objects may be used in policies (orpolicy objects). Alternatively, a policy author may define abstractionobjects based on the requirements of a set of policies.

While abstraction objects are the building blocks of policy objects,entity objects are the building blocks of abstraction objects. An entityobject may represent a physical entity, a logical entity, an event (oraction) entity, a contextual entity, and more.

Typically, the physical entities that may be found in an organizationinclude users, recipients, applications (e.g., Microsoft Word), devices(e.g., printer, PDA or smartphone), computers, file servers,directories, files, database records, mailboxes on a mail server, or aMicrosoft SharePoint Server object. Some examples of a physical entityspecification include ‘a user name equals “john.doe”,’ ‘a computer nameequals “desktop005”,’ or ‘a file share starts with “\\serverX\”.’

A logical entity is a group of one or more entities. Entities may beorganized into a group based on their characteristics (e.g., allspreadsheet files), or manually assigned (e.g., an Active Directory usergroup “finance staff”). Logical entities are often objects found in arepository (such as user group in a LDAP directory) that are logicalrepresentations of physical entities (such as users) found in the samerepository. Logical entities may also represent a logic name of a classof entities (e.g., removable media or optical disks). Logical entitiesmay include user groups, mailing list, types of applications (e.g.,spreadsheet or instant messenger), types of devices (e.g., PDA), groupsof computers (e.g., legal department computers), types of computers(e.g., laptop, desktop or server), file shares, groups of documents(e.g., any files that contain personal private information, documentsthat are classified confidential, or documents containing customerinformation), printers, storage devices, removable media, or USBdevices.

Event entities represent events that are generated either by hardware orsoftware. An event may be directly or indirectly attribute to a useraction such as opening a file using a desktop application or submittingan on-line form using a web browser. An event may also be an attributeof an application program operation such as maturation of a scheduledtask. Common event entities include open, save, delete, copy, move,send, and connect.

Contextual entities are often used in constructing policy contexts(described further below). Contextual entities may include time, timeranges, types of connectivity (e.g., VPN or WLAN), bandwidth,point-of-use locations (e.g., New York office), or points of access to anetwork (e.g., LAN, Internet or dialup).

In addition, there are also entity objects that do not fall into one ofthe physical, logical, event and context classifications. The entityobjects includes universal resource locators, connection strings,commands such as SAP command strings, or query strings such as SQLstatements.

There are many sources of entity objects (these sources of entityobjects are referred to as “entity object data source” in thefollowing). Typically, an entity object data source provides some of theentity objects require to evaluate a policy object. A policy enforcermay access one or more entity object data sources to complete evaluationof a policy object. Alternatively, a policy enforcer may access a metaentity object data source that provides transparent access to multipleentity object data sources through federation or aggregation of entityobject data sources.

In a typically enterprise environment, entity objects may be found on adirectory server (e.g., a LDAP server or Microsoft Active Directory), asystem or network management server (e.g., HP OpenView), an applicationserver (e.g., Oracle Finance, Microsoft .NET server, or Java 2Enterprise Edition server), or a database server. Entity objects mayalso be found in a computer registry (e.g., Windows registry), aperformance, system or network management data repository, a database, aconfiguration file, or a data file. Some entity objects may not bestored in a repository, but collected at a policy enforcement point oraccessible to a policy enforcer through an API to an operating system ora program library. In an example, entity objects may be properties of anActive Directory object such as employee's job title, employee's branchlocation, or name of an Active Directory group.

In a specific implementation of the invention, the Blue Jungle CompliantEnterprise policy enforcement system stores policy objects in a PolicyMaster (a policy objects database), apportions storage of abstractionobjects between the Policy Master and an Information Network Directory(a meta directory of resource abstraction objects and entity objects),and stores entity objects in the Information Network Directory.

The following example illustrates a policy constructed according to thethree layer structure. A policy object named “Executives Only” thatprevents any user other than executives from accessing documents storedin a restricted folder. The policy object refers to executives definedby an abstraction object named “Executives.” The abstraction objectcomprises of a list of user names where each user name refers to anentity object. The example also shows the three entity objectsreferenced by the abstraction object.

# Policy Object 1 - Executives Only FOR document.name =“\\server123\restricted\*.doc” ON OPEN BY user = Executives DO ALLOWOTHERS DENY # Abstraction Object 1 - Executives Executives = jcarter,gbush, pjones # Entity Object 1 - JThomas User.name = jthomas # EntityObject 2 - WMannings User.name = wmannings # Entity Object 3 - PJonesUser.name = pjones

In an implementation, an example of an operation of the structure isthat when there is a change in an abstraction object in the secondlayer, there will be a corresponding change in any policy object in thefirst layer including a reference to the abstraction object.

The following example illustrates the effect of changing an abstractionobject of the abstraction object layer has on policy objects of policyobject layer. The example shows two policies that are design to controlreading and copying of documents in a restricted folder. The policiesspecify a user who is an executive can read and copy documents stored ina restricted folder, but copy operations are recorded in a log. Thepolicies are constructed according to the three layer structure withpolicy objects “Executives Read” and “Executives Copy,” abstractionobject “Executives” and entity objects “JThomas,” “PJones,” and“JConwell.” Both policy objects “Executives Read” and “Executive Copy”reference abstraction object “Executives.” Abstraction object“Executives” references entity objects “JThomas”, “PJones” and“JConwell.”

The example shows the two policy objects and their equivalent forms attime t0 and t1 to illustrate the propagation of a change from anabstraction object to multiple policy objects, where t0 precedes t1. Attime t0, the two policy objects were enforced at a policy enforcer in anorganization. Assuming at a time between t0 and t1, a new executive“John Conwell” joined the organization. Abstraction object “Executives”was updated to include the new executive “JConwell.” At time t1, thechange in the abstraction object was propagated to the policy enforcerand the policy enforcer began to enforce the policy objects based thechanged abstraction object.

To help illustrate the effect of the change, equivalent forms of the twopolicy objects at time t0 and t1 are provided. The equivalent form of aparticular policy object is a functional equivalent of the particularpolicy object. A comparison of the policy object “Executives Read” inits equivalent forms at time t0 and t1 shows that the change occurred inabstraction object “Executives” is propagate to policy object“Executives Read” at time t1. Similar, further examination of theequivalent form of policy object “Executives Copy” also shows that thechange in abstraction object “Executives” is propagated to policy object“Executives Copy” at time t1.

# Policy definition at time t0 - before change to abstraction object #Policy Object 1 - Executives Read FOR document.name =“\\server123\restricted\*.doc” ON OPEN BY user = Executives DO ALLOWOTHERS DENY # Policy Object 2 - Executives Copy FOR document.name =“\\server123\restricted\*.doc” ON COPY BY user = Executives DO (ALLOWAND LOG) OTHERS DENY # Abstraction Object 1 - Executives Executives =jthomas, pjones # Entity Object 1 - JThomas User.name = jthomas # EntityObject 2 - PJones User.name = pjones # Policy definition at time t1 -after change to abstraction object (adding one executive) # PolicyObject 1 - Executives Read FOR document.name =“\\server123\restricted\*.doc” ON OPEN BY user = Executives DO ALLOWOTHERS DENY # Policy Object 2 - Executives Copy FOR document.name =“\\server123\restricted\*.doc” ON COPY BY user = Executives DO (ALLOWAND LOG) OTHERS DENY # Abstraction Object 1 - Executives Executives =jthomas, pjones, jconwell # Entity Object 1 - JThomas User.name =jthomas # Entity Object 2 - PJones User.name = pjones # Entity Object3 - JConwell User.name = jconwell # Policy definition (in equivalentform at time t0 - before change to abstraction object # Policy Object1 - Executives Read FOR document.name = “\\server123\restricted\*.doc”ON OPEN BY user = jthomas, pjones DO ALLOW OTHERS DENY # Policy Object2 - Executives Copy FOR document.name = “\\server123\restricted\*.doc”ON COPY BY user = jthomas, pjones DO (ALLOW AND LOG) OTHERS DENY #Entity Object 1 - JThomas User.name = jthomas # Entity Object 2 - PJonesUser.name = pjones # Policy definition in equivalent form at time t1 -after change to abstraction object # (adding one executive) # PolicyObject 1 - Executives Read FOR document.name =“\\server123\restricted\*.doc” ON OPEN BY user = jthomas, pjones,jconwell DO ALLOW OTHERS DENY # Policy Object 2 - Executives Copy FORdocument.name = “\\server123\restricted\*.doc” ON COPY BY user =jthomas, pjones, jconwell DO (ALLOW AND LOG) OTHERS DENY # Entity Object1 - JThomas User.name = jthomas # Entity Object 2 - PJones User.name =pjones # Entity Object 3 - JConwell User.name = jconwell

In an implementation, an example of an operation of the structure isthat when there is a change in a value of an entity object in the thirdlayer, there will be a corresponding change in any policy object in thefirst layer including a reference to the entity object or an abstractionobject in the second layer including a reference to the entity object.

In other implementations of the invention, there may be a differentnumber of layers. Information in two or more layers of one system may bepresented in a single layer in another system. For example, animplementation of the invention may have two layers only, a policyobject layer and an abstraction object layer, where the entity objectlayer is provided in the abstraction object layer. In furtherimplementations of the invention, there may be two, three, four, five,six, seven, eight, or more layers.

As has been discussed, the policy language system of the invention maybe applied to multiple types of information. The policy language systemof the invention may also be applied to many different types ofapplications not only information or document management. Otherapplications may include policy management for network traffic,firewall, e-mail, spam, digital media rights, and many others. Forexample, when managed using a policy language of the invention, networktraffic or digital media rights will be managed using policies thatreference abstractions, which may in turn reference entity information.

This application describes the structure of a policy language. Althougha particular structure and syntax are described, it is not intended thatthe invention be limited to the structure of syntax described. There aremany possible structures and syntaxes for a policy language, and any ofthese may be used to implement a system of the invention.

In an implementation of the invention, a plurality of policy objects inthe policy object layer implements information usage control on acomputer system, where a policy enforcer (discussed elsewhere in thisapplication) detects usage of information, evaluates policies (or rules)specified by the policy objects, and enforces policies according tooutcomes of policy evaluation.

In the implementation of information usage control, an entity objectlayer comprises of a plurality of entity objects representing any of:resource (e.g., file, e-mail, Web page, on-line report, or result set ofa database query), user, action, time, location, connectivity (e.g.,VPN, WLAN, dialup, RDP, VNC, or latency), application (e.g., MicrosoftWord, SAP Frontend client application, spreadsheet, or instantmessenger), and more. An entity object may comprise of a name (oridentity) and a value. A value may be an integer, a floating pointnumber, a Boolean value, a string or a reference. Further, an entityobject may also comprise of a name and multiple values, or a name and adata object. In one embodiment, entity objects may be stored in a LDAPserver, a database, a system registry, a configuration file or anycombination thereof. An entity object may be reference by its name (oridentity). In an embodiment, an entity object is called one of event,resource, subject or context in a policy language described furtherbelow. For example, a reference to an entity object may take the formof: user=“John Doe,” action=OPEN, application=“Microsoft Word,”computer=“Jane's desktop,” or location=“Boston Office.”

In the implementation of information usage control, an abstractionobject layer comprises of a plurality of abstraction objects. Anabstraction object is typically a logical representation of a collectionof entity objects. An abstraction object may comprise of a name (oridentity) and an expression that refers to one or more entity objects.An abstraction object may also refer to another abstraction object. Oneor more abstraction object may refer to a particular entity object inthe entity object layer. In an embodiment, an abstraction object iscalled a policy abstraction in a policy language described furtherbelow. For example, a reference to a policy abstraction may take theform of: user=Finance, document=Legal-Documents,computer=Guest-Workstations, application=Instant-Messenger,location=Branch-Office, or connectivity=Remote.

In the implementation of information usage control, a policy objectlayer comprises of a plurality of policy objects that refer to one ormore abstraction objects in the abstraction object layer and one or moreentity objects in the entity object layer. One or more policy objectsmay refer to a particular abstraction object in the abstraction objectlayer. One or more policy object may refer to a particular entity objectin the entity object layer. In an embodiment, a policy object is calleda policy in a policy language described further below.

In an implementation of the invention, a plurality of policy objects inthe policy object layer implements document access control on a computersystem, where a policy enforcer (discussed elsewhere in thisapplication) detects accesses to documents, evaluates policies (orrules) specified by the policy objects, and enforces policies accordingto outcomes of policy evaluation.

In the implementation of document access control, an entity object layercomprises of a plurality of entity objects representing any of:resource, subject, event, and context. An entity object may comprise ofa name (or identity) and a value. An entity object may also comprise ofa name and multiple values, or a name and a data object. Above theentity object layer is an abstraction object layer which comprises of aplurality of abstraction objects. An abstraction object is typically alogical representation of a collection of entity objects. An abstractionobject may comprise of a name (or identity) and an expression thatrefers to one or more entity objects. An abstraction object may alsorefer to another abstraction object. One or more abstraction object mayrefer to a particular entity object in the entity object layer. Thelayer above the abstraction layer is a policy object layer whichcomprises of a plurality of policy objects. A policy object may refer toone or more abstraction objects in the abstraction object layer, one ormore entity objects in the entity object layer, or combination of both.One or more policy objects may refer to a particular abstraction objectin the abstraction object layer. Similarly, one or more policy objectmay refer to a particular entity object in the entity object layer. Inan embodiment, the objects in the three layers described here representelements in a policy language describe below, where a policy object isreferred to as a policy, an abstraction object is referred to as apolicy abstraction, and an entity object is referred to as one of event,resource, subject or context.

A policy language of the invention may include a number of terms wheremany of them are optional under certain circumstances and a policy canbe built from zero or more of each term, in any combination, including alogical expression, mathematical expression, or statement of any sort(including Blue Jungle ACPL or other variations). These can be nested asneeded or desired. When a term can be optional under certaincircumstances, this means a reaction rule generally has at least oneevent to react to and one effect to describe the control action. Othersterms are optional. However, for a maintenance rule, the event may beoptional (normally, an internal event is included) and the effect is notrequired. In a maintenance rule, an obligation task or a remediationtask is likely used for the rule to be useful. However, one can alterthe policy language syntax and move the task into the premise making thetask a side effect of a condition. So tasks are not necessary becausedeployment can occur even when tasks are not specified.

Below is an outline of some terms in an implementation of a policylanguage. Although they are referred to as terms, they may also becalled term elements.

A rule or policy includes an expression. A premise can be an expressionor statement. More specifically, a premise can contain an expression,and an expression can be a statement. An expression may be “a=true andb=c.” An expression may also include a comma delimited list. Forexample, one may check whether an action is one of the actions listed ina comma delimited list. A statement may be “FOR expression ON expressionBY expression DO statement,” or any nonlogical or mathematicalexpression. As in the above example, a statement includes expressions,potentially multiple expressions, each of which may be nested. Thestatement may also include nested statements.

policy:=premise+consequence+directives

A premise generally refers to terms such as events, resources, subjects,context, policy abstractions, and directives. Not all of the terms in apremise are required. A premise is sometimes called a condition. Apremise can be a simple Boolean expression that evaluates to true orfalse at run time, a simple statement with at least one expression, or acomplex statement composes of multiple parts, each part consists ofnested statements or subexpressions, and more. Any one of the aboveterms can appear one or more time in an expression, a subexpression or astatement. Each term can also appear in more than one expression,subexpression or statement within the premise. A consequence generallyrefers to an effect, obligation tasks, or remediation tasks. For apolicy that implements control function, an effect is required butobligation tasks and remediation tasks are optional. In a policy thatdoes not implement control function, an effect is optional. A policy cancontain any number of directives to assist in policy deployment, affectpolicy evaluation or carry instruction that influence any one of thestages in a policy lifecycle.

Below are more details on a structure of a policy component or parameterin a pseudo language format. A policy component is typically definedusing an expression or a statement and this expression or statement mayinclude a policy abstraction. An expression or statement may include anynumber of policy abstractions, such as no policy abstractions, or one ormore policy abstractions. A policy can contain an expression or astatement. A policy abstraction can be nested.

The “:=” symbol specifies the term on the left-hand side (LHS) can beexpressed with what is specified on the right-hand side (RHS). The “{ }”symbols denote a set of terms where any combination of one or more ofsuch terms can form a specification where the specification includes alist, an expression, or a statement. The “ . . . ” symbol denotesadditional terms not completely enumerated.

premise := {events, resources, subjects, recipients, context, historicalevents, policy abstractions, directives} consequence := {effect,delegate, obligation tasks, remediation tasks, directives} policyabstraction := {events, resources, subjects, context, policyabstractions, directives} event := {actions, exceptions, scheduledevents, internal events, external events, directives, ...} resource :={documents, containers, application programs, devices, networks,subnets, resource sets, directives, ...} subject := {users, user groups,application programs, devices, directives, ...} recipient := {users,user groups, e-mail addresses, mailing lists, application programs,directives, ...} context := {time, locations, organizational units,connectivity, events, resources, subjects, policy abstractions,directives, historical data, activity statistics, external data, ...}document := {file system objects, e-mail messages, data objects managedby a messaging server, data objects managed by a collaboration server,data objects managed by or served by a Web server, data objects managedby a portal server, data objects managed by a document managementsystem, data objects managed by a content management system, dataobjects managed by an application server, ...} container := {containersin an application server, virtual machines hosting application programs,virtual machines hosting operating systems, workflows, discussiongroups, ...} application program := {word processors, spreadsheets,e-mail clients, instant messengers, command shells, financialapplications, office productivity applications, Microsoft Excel, YahooMessenger, ...} device := {desktop computers, laptop computers, servers,personal digital assistants, smart phones, thin clients, informationkiosks, legal department computers, database servers, cash registers,engineering-server-128, 31.112.100.1, storage devices, networkingdevices, ...} resource set := {groups of documents, groups ofapplication programs, groups of devices, groups of network addresses,categories in a document management system, ...} connectivity := {VPN,LAN, WLAN, WAN, Bluetooth, Internet, DSL, ISDN, dialup, bandwidth,subnet address, ...} effect := {ALLOW, DENY, INDETERMINATE, query user,delegate, custom effect, ...} delegate := {evaluate another policy orset of policies locally, invoke evaluation of a policy or a set ofpolicies in a another policy engine on the same device or differentdevice} obligation task := {LOG, NOTIFY, ARCHIVE, ENCRYPT, MODIFY,custom tasks, ...} remediation task := {ERASE, CLEANUP, custom tasks,...}

There may be a premise policy component, which identifies what thepolicy is for. For example a premise policy component may be for certaindocuments or information, or classifications of documents orinformation, or devices or portion of a network.

A premise may be described using a statement or an expression containingevents, resource, subjects, contexts, policy abstractions or directives,or combinations of these, or other statements or expressions. Thestatement can be a simple statement, or a complex statement containingmultiple nested statements and expressions, or any other manner ofmaking a statement. When evaluated with a collection of input data(including data of an intercepted operation), the statement determineswhether a policy is relevant to the policy evaluation request (theconsequence defined in the policy does not apply if the policy is notrelevant), and if the policy is determined to be relevant, what part ofthe policy consequence will apply to the determination of a finalconsequence.

For example, in a policy that performs control function, there may be apositive consequence and a negative consequence defined in a policy. Inthis case, a statement of a relevant policy determines whether thepositive consequence or negative consequence will apply. In anotherexample, for a policy that does not implement control function, theremay be only one consequence, and the statement only need to determine ifa policy is relevant before the consequence will be used in determiningthe final consequence. The expression may be given in Boolean, string,keyword, or integer format, or any other manner of making an expression.There may be subexpressions for event, resource, subject, context, ordirective, or combination of these.

In a specific implementation, a policy language definition may specifythat only one policy may be relevant to a policy evaluation request. Inthis case, policy evaluation involves selecting the relevant policybased on a set of input data associated with a policy evaluationrequest. The relevant policy selection process includes evaluating thestatement or expression in a policy to determine if the policy isrelevant. The evaluation step can be carried out on a policy in itsnative format, or in any other forms including result of optimization,transformation (like from text to binary), or translation (from onepolicy language to another policy language). Once a policy is determinedto be relevant, the outcome of policy evaluation will include theapplicable portion of the consequence.

The following covers policy language and policy engine that support morethan one relevant policy associated with an operation. In this case,there will be more than one policy consequence (one from each policy)and the result will be combined with an combining algorithm. There aremany possible different algorithms, including taking the first policyconsequence, one deny will deny all, one permit will permit all, and soforth.

In a further implementation, a special policy may override a combiningalgorithm or alter the function of a combining algorithm, thereforechanging the outcome of policy evaluation. For example, an organizationhas a set of policies that dictate sending confidential information viae-mail messages by an organization personnel. When a consultant is hiredto work on a set of confidential documents, a policy author writes an adhoc policy to temporarily override the normal access control policies onthe set of confidential documents by the consultant for a specificperiod of time on a specific computer that is protected by a policyenforcer.

In a specific implementation, a policy language definition may specifythat one or more policies may be relevant to a policy evaluationrequest. In his case, policy evaluation involves selecting all relevantpolicies based on a set of input data associate with a policy evaluationrequest. The relevant policy selection process includes evaluating thestatement or expression in a policy to determine if the policy isrelevant. The evaluation step can be carried out on a policy in itsnative format, or in any other forms including results of optimization,transformation (like from text to binary), or translation (from onepolicy language to another policy language). Once a policy is determinedto be relevant, the applicable portion of the consequence will beconsidered together with applicable portion of consequences of otherrelevant policies to determine a final outcome of policy evaluation.

For the premise, an event that a policy associates with can be anaction, exception, scheduled event, internal event, or external event.The most common event for policies that implement control function isthe “action” event. A system that implements control function normallyimplements an authorization process which can include one or moreinterceptors intercepting user actions, application program operationsor operating system operations, or application program logic thatperforms authorization before user actions or application programoperations are carried out. The authorization process can be applied touser actions, application or operating system events or operations.Interception can occur at an application program, at operating systemlibrary, and at device driver.

For example, in a financial application (e.g., Bloomberg or Fidelitytrading application), an action may correspond to a trading ordersubmission operation. In this case, the trading order submissionoperation is intercepted (or detected), information related theintercepted action is forwarded to a policy decision point, andconsequence is applied according to the policy decision produced by thepolicy decision point.

Another type of event is “scheduled event.” The scheduled event involvesa scheduler which may be running locally or remotely. Policy evaluationis triggered when a scheduled event matures. A common use of a scheduletrigger includes carrying out document retention policy by deletingdocuments older than, for example, 90 days or 7 years, transferringdocument to archive storage, encrypting confidential documents that havenot be properly protected, and performing an auditing or investigativetask that requires collecting all documents meeting a certain criteria.

An “internal event” is one generated by a policy engine or othercomponents of a system of the invention. Such event may be generated asa result of a policy evaluation request or a result of an activity dataanalysis operation.

An “external event” is one that is invoked by another applicationoutside of a system of the invention. Such an application is normally athird party application integrated with the system of the inventionthrough a software development kit (SDK). Third-party applicationintegration can be extremely useful because in a specific implementationwhere policy enforcers are deployed company-wide managing all types ofinformation, the management system has access to information in adistributed environment without going through additional authenticationand authorization processes. For example, a customer relationshipmanagement (CRM) application may instruct the management system toarchive all documents related to a customer on closing of an account.This may include rolling up files on file servers, and desktop andlaptop computers, e-mail messages on mail servers and all mail clients,documents in document management systems, and databases.

There may be a consequence policy component. The consequence may includeeffect, obligation, or remediation tasks, or combinations of these, orothers. Once the policy is identified as relevant to a particular policyevaluation request, there will be a corresponding consequence.

There may be an effect policy component. An effect is normallyassociated with a policy that implements control function. The effect ofsuch policy may include allow, deny, indeterminate, query user,delegate, custom effect, or others. Allow may refer to allowing accessto some information. Deny may refer to disallowing access to someinformation.

There may be an obligation policy component. The obligation parametermay include log, notify, archive, encrypt, or modify, or any combinationof these, or others. Log instructs the system to log an event oractivity. Notify instructs the system to notify an individual or user(such as sending an e-mail) when a certain event occurs. Archiveinstructs the system to archive information. For example, for particulare-mails, they may need to be archived for compliance with securities orother laws. Encrypt instructs the system to encrypt information. Forexample, for some e-mails, which may include a specific type of e-mailor an e-mail to a particular addressee, or just someone outside thecompany, the system will automatically encrypt the e-mail before it issent. Modify instructs the system to modify the information associatedwith policy evaluation request. An example of a modify obligation maychange the subject line of an e-mail message to include a tag element toidentify the message is under export control or should considerconfidential.

There may be a remediation policy component. Remediation refers to tasksnot directly related to current policy evaluation request that ought tobe carried out. Remediation tasks can be any specified task.

There may be a delegate policy component. The delegate parameter may beused to pass operation to (or call) another policy. Using the delegateparameter, the result of executing a first policy may be to includeexecuting a second policy, different from the first policy.

In some policies, the policy consequence may include a positiveconsequence, a negative consequence, and optionally an indeterminateconsequence. A positive consequence is adopted when evaluation of apremise produces a positive result. A negative consequence is adoptedwhen evaluation of a premise produces a negative result. Anindeterminate consequence is adopted when evaluation of a premise cannotbe completed. As an example, evaluation of premise can fail to completeif a premise specifies an input value that is not available or containsan invalid value.

Other policies may include just one policy consequence which is adoptedwhenever a policy is determined to be relevant. Policies may elect tosupport any combination of positive consequence, negative consequenceand indeterminate consequence.

Depending on how a policy engine is implemented and whether it supportsone or more policy combining algorithms, the meaning of adopting apolicy consequence or a portion of a policy consequence also varies. Ina policy engine supporting only one relevant policy per policyevaluation request, or a policy engine that selects the first relevantpolicy, or a policy language syntax that supports specifying policyevaluation should based on first relevant policy in a policy set, therelevant policy's consequence or portion of the relevant policy'sconsequence will become the outcome of policy evaluation.

On the other hand, if policy evaluation can result in more than onerelevant policy, the combined results of all relevant policies should beused to determine the outcome of policy evaluation. In such situation, acombining algorithm should be used. Some common combining algorithmsinclude deny-override and permit-override. A deny-override combiningalgorithm specifies that if evaluation of the premise of any relevantpolicy result is a deny effect, the outcome of the policy evaluation isdeny. A permit-override combining algorithm specifies that if evaluationof the premise of any relevant policy result is a permit or alloweffect, the outcome of the policy evaluation is permit or allow.

A policy effect is not required in all policies. Typically, a policythat implements control function should include at least a positivepolicy effect. If a negative policy effect is not specified in the samepolicy, the negation of the positive policy effect is assumed. Thepolicy effect of a policy that implements control function may includeALLOW, DENY and INDETERMINATE. For policy associated with a policyevaluation request caused by user interaction with a system, a policyengine may support querying user for a policy effect. In this case, thepolicy effect provided by a user will be adopted.

Furthermore, a policy can delegate the determination of a policy effectto another policy to be evaluated using the same input data in the samepolicy engine or in another policy engine. In this case, the outcomeproduced by the delegated evaluating a policy or a set of policies isadopted. Such delegation of policy evaluation can apply to a positivepolicy effect, a negative policy effect, or an indeterminate policyeffect, or any combination of these.

The policy language structure described can also support an extensionmechanism that allows a policy effect to be produced by a custom effecthandling function. For example, custom policy effect handler may beimplemented in a method (or function or procedure) in an in-houseapplication program. One or more methods in the in-house applicationprogram can call a policy engine in a policy enforcer to invoke policyevaluation. The result of policy evaluation can be a custom policyeffect that can be handled by the one or more methods (e.g., executedifferent code based on the value of a custom policy effect). In thiscase, execution of some functionalities in the in-house applicationprogram can be controlled by a set of policies defined by a policyauthor.

Obligation refers to tasks related to a policy evaluation request thatis being processed that a policy engine is obliged to complete. Anobligation may include logging, notifying a user or a management system,archiving certain data associated with the policy evaluation request,encrypting data associated with the policy evaluation request, ormodifying the data associated with the policy evaluation request, or anycombination of these, and more. Remediation refers to tasks not directlyrelated to current policy evaluation request ought to be carried out.Remediation tasks can be any specified task. For example, when a userchanges jobs within an organization, the user may not be given access toinformation the user previously had access to, a policy may specify aremediation task that deletes the files the user copied onto a harddrive of his system.

There may be an action policy component. Some examples of actionsapplied to document access control include open, save, print, copy,delete, and move. There may be other actions a system watches for orhandles. Open may be opening a document or other information such as ane-mail. Save may be saving a document or other information such ase-mail. Print may be printing a document or portion of a document. Copymay be copying a document or other information such as an e-mail. Deletemay be deleting a document or other information such as an e-mail.

Move may be moving a document or other information such as an e-mail.Moving may include actions such as moving information from one folder ordirectory to another, from one server to another server, or from onemachine to another machine, or generally from location to a differentlocation.

The semantics of policy actions is specific to what type of applicationa policy is intended for. For example, policy actions for applicationusage control may include print, send, forward, cut, paste, drag, drop,edit formula, edit macro, edit script, change document property, editingportion of a document, connect to the network and so forth.

There may be a subject policy component. A subject may include users,user groups, applications, devices, policy abstractions, or combinationsof these, or others. An example of users may be specifically identifiedusers of the system. They may be specified using a user name, a useridentifier, or other similar identifier. An example of user groups maybe users who are in a particular department, such as the legal oraccounting department. User groups may also include those defined in adirectory server (such as a LDAP server).

There may be a recipient policy component. A recipient may includeusers, user groups, e-mail addresses, mailing lists, applicationprograms, or combination of these, or others. An example of users may bespecifically identified users of the system. They may be specified usinga user name, a user identifier, or other similar identifier. An exampleof user groups may be users who are in a particular department, such asthe legal or accounting department. User groups may also include thosedefined in a directory server (such as a LDAP server). An example of amailing list may be a mailing list managed by a mail server or a mailclient application.

There may be a device policy component. A device may be specificworkstations. For example, some workstations may be designated as publicworkstations and more security is used when a user or person accessesinformation of the system using a public workstation. Devices may alsoinclude types of devices such as laptops, desktops, personal digitalassistants, smart phones, information kiosks, terminal servers, databaseservers, network attached storages, storage devices, file gateways,network devices, firewalls, routers, load balancers, switches, and soforth. Devices may also include groups of computers which may specifydevices in the finance department, engineering workstations, branchoffice computers, and so forth.

There may be an application policy component. An application may besoftware such as Microsoft Word, Yahoo Instant Messenger, MicrosoftMessenger, Skype, Microsoft Outlook, Qualcomm Eudora, Oracle databaseapplication, a Microsoft Office application, a word processing program,e-mail program, photo manager, file manager, database server, webserver, messaging server, or Apache server.

There may be a context policy component, which is a context under whichthe policy is applied or not applied (or relevant or not relevant), or apolicy expression should evaluate to true or false. A context mayinclude a time, location, organizational unit, connectivity, or other. Atime is a time period, such as when a policy goes into effect or becomesno longer effective. A policy may be apply or be restricted based on alocation, such as a group of users, but only at a specific location. Forexample, by using an appropriate combination or subject and context, apolicy may apply to members of the accounting department in California,but not in Texas.

There may be a “historical event” policy component. The historical eventpolicy component is part of a premise of policy which specifies one ormore events that need to happen before the current event. The historicalevent component may also specify a time window in which the historicalevents should be inspected. The historical event component may alsospecify whether historical events should occur in a specific order.Other parameters that a historical event component may specify includewhether historical events should occurs in a specific order, number oftimes each historical event has occurred, or number of times a specificlist of historical events have occurred.

The context policy component may contain a simple expression thatspecifies a time or location. It can also specify a complex expressionincluding any combination of events, resources, subjects, policyabstractions, historical data, activity statistics, external data, andmore.

There may be a resource policy component. A resource may includedocuments, containers, application programs, devices, networks, subnets,resource sets, policy abstractions, or directives. Documents mayinclude: file system objects such as files and directories; data objectsmanaged by a messaging server such as e-mail and contacts; data objectsmanaged by a collaboration server such as discussion threads,whiteboards, shared folders, calendars and contacts; data objectsmanaged by a document management systems such as files, messages,document groups, categories, workflows and indexes; data objects managedby a portal server such as HTML pages, JSP pages, ASP pages, portlets(i.e., Java Community Process JSR 168 Portlet Specification), widgets,files and discussion threads, and more. Containers may includecontainers in an application server such as J2EE application servers,containers hosting application programs such as those supported bySolaris 10 or Microsoft Windows Vista, virtual machines such as Javavirtual machines or Python virtual machines, containers hostingoperating systems such as VMWare Virtual Server and Microsoft VirtualServer 2005. A resource policy component may also specify an applicationprogram, a group of application program such as “Microsoft OfficeApplications,” “operating system utilities,” or a type or class ofapplication program such as spreadsheet and instant messenger.

There may be a connectivity policy component. The connectivity parametermay include VPN, LAN, WLAN, WAN, Bluetooth, Infrared, Internet, DSL,ISDN, dial-up, or bandwidth, or a combination of these. These parametersdenote a type of connection that is being used to connect to the system.VPN is a virtual private network connection. LAN is a local area networkconnection, such as Ethernet. WLAN is a wireless local area network suchas a Wi-Fi, 802.11a, 802.11b, 802.11g, 802.11n, Wi-Max, or otherwireless network. Bluetooth is a wireless connection. Dial-up refers toconnecting through a phone line, typically using a modem. Bandwidthrefers to connecting to the system with a particular bandwidth, such as56K bits per second, 10 megabits per second, 100 megabits per second, or1 gigabits per second.

There may be a “policy abstraction” component. The policy abstractioncomponent contains a statement or expression. The statement orexpression may evaluate to a string, integer, floating point, or Booleanvalue. The statement or expression may also evaluate to a compoundobject. Typically, a policy abstraction contains a Boolean expression.

In some implementation, a policy abstraction may include two or morevariable definitions. Each variable in the policy abstraction includes aname and a definition. A variable definition may comprise an expressionor a statement where the expression or statement may refer to anothervariable in the policy abstraction or another policy abstraction.

There may be a directive component. The policy directive component maybe used to provide instruction to a policy engine, or instruct a policyengine that a policy should meet certain requirement. For example, apolicy may contain a directive that instruct the policy engine to ensurethat the destination of a copy operation be protected by a policyenforcer. The policy directive component may also be used to instructpolicy deployment logic what type of target a policy is designed for sothat the policy can be deployed to an appropriate target. For example, apolicy is design for Microsoft Exchange Server, a policy author can adda directive to the policy to assist policy deployment. In anotherexample, a policy may be appropriate to a specific version of Linuxoperating system, a policy directive can be added to ensure correctpolicy deployment.

There may be a historical data component, which may also be referred toas activity data. A historical data component may specify recent eventdata, aggregated event data, or statistical data stored in volatilememory or nonvolatile memory. Historical data may be stored in ahistorical database. In system, as shown in FIG. 5, there may be anintelligence server designated to handle this historical or activitydata. The historical database may also be referred to as a log andintelligence repository. In other implementations, the historical dataand historical data gathering may be incorporated in the policy server.In other words, the policy server and intelligence server functions maybe provided by a single server.

Unlike existing entitlement or access control system (includingACL-based solution) where control access to resources is based onpolicies specifying who can access a resource (e.g., owner or users whoare given read or write access) and what action can be applied to aresource (e.g., create, read, write or edit, delete, or visible to otherusers), the policy language in the invention allows who, what, when,where, how, to whom, or any combination of these to be expressed in apolicy.

For a policy of the policy language, the “who” element of the policy maybe specified using a subject policy component. For example, a subjectpolicy component may specify who can read a document, or who can sendconfidential document to a particular recipient.

The “what” element in a policy of the policy language may be specifiedusing a resource policy component, an event policy component, or anycombination of these. For example, a policy may specify what resourcesmay be accessed by a user, or what action a user may carry out on aresource.

The “when” element in a policy of the policy language expresses eventand time aspects of a policy. The “when” element may be specified usingan event policy component, a context policy component, or anycombination of these. For example, a policy may specify when aparticular action is invoked by a user, and what obligations (or tasks)should be implemented. In this case, the “when” element is the actioninvoked by the user. In another example, a policy may specify when anevent is detected at a particular time, what consequence should beimplemented. In this case, the “when” element refers to the particulartime which may be a time of a day, a time range, a day in a week, orothers.

The “where” element in a policy of the policy language expresses thelocation aspect of a policy, and it may be specified using a contextpolicy component. In one example, a policy may specify a user can onlyaccess a resource within a company's main office. In this case, the“where” element is the main office. In another example, a policy mayspecify if a user access a resource from a computer that is not secure,the access should not be allowed. In this case, the “where” elementrefers to the computer.

The “how” element of a policy of the policy language expresses themechanism through which a resource is accessed. The “how” element may bespecified using at least one subject policy component, context policycomponent, or combination of these. For example, a policy may specify ifa user access a document through a type of connectivity such as VPN orLAN, the access should be allowed. However, if a user access a documentthrough connectivity such as WLAN, the access should not be allow. Inthis case, the “how” element refers to connectivity types such as VPN,LAN or WLAN. In another example, a policy may specify if a user accessesa document through a specific application program such as a FTP clientapplication, the access should not be allowed. In this case, the “how”element refers to a specific application program.

The “to whom” element of a policy of the policy language expresses therecipient aspect of a policy, and it may be specified using recipientpolicy component. For example, a policy may specify a confidentialdocument may be sent only to personnel within a company. In this case,the “to whom” element refers to personnel within a company which may bespecified based on a user group, a domain name in an e-mail address, orothers.

In a specific implement of the policy language that does not include arecipient policy component, the “to whom” element may be implementedusing a resource policy component. In this case, the recipients who areallowed to (or not allowed to) receive a resource may be specified in aresource policy component.

The Blue Jungle ACPL is a specific implementation of a policy languagedescribed in this invention. In particular, ACPL comprises of ACPLPolicies and Policy Components where an ACPL Policy corresponds to apolicy of the policy language and a Policy Component corresponds to apolicy abstraction of the policy language.

Below is a specific implementation of a policy language including keywords or tokens. The tokens in this example are FOR, ON, BY, WHERE, DO,OTHERS, ALLOW, DENY, AND, OR, and NOT. In an implementation, the tokensmay be case sensitive and they may be typed in all capitals to indicateto the system they are tokens. However, in other implementations, thetokens of the language may be case insensitive and the lower case wordswill be recognized by the system as being tokens.

policy := FOR <resource expression> ON <event expression> BY <subjectexpression> WHERE <context expression> DO <positive consequence> OTHERS<negative consequence> positive consequence := effect AND <obligationtasks> AND <remediation tasks> negative consequence := effect AND<obligation tasks> AND <remediation tasks>

The policy language includes a number of elements. The premise iscomprised of a resource element (or FOR element), an event element (orON element), a subject element (or BY element), and a context element(or WHERE element). The consequence is comprised of a positiveconsequence element (or DO element) and a negative consequence element(or OTHERS element). Following the FOR token, there is a resourceexpression. Following the ON token, there is an event expression.Following the BY token, there is a subject expression. Following theWHERE token, there is a context expression. Following the DO token,there is a positive policy effect and optionally a list of obligationtasks each separated by an AND token and a list of remediation taskseach separated by an AND token. Following the OTHERS token, there is anegative policy effect and optionally a list of obligation tasks eachseparated by an AND token and a list of remediation tasks each separatedby an AND token. Not all elements in a premise are required. Negativeconsequence element is also optional.

The resource element (or FOR element) in the policy language specifies alogical expression (i.e., resource expression) that describes one ormore policy abstractions (e.g., document=Confidential ORmessage=Sensitive), or one or more document attributes and correspondingmatching patterns (e.g., ‘document.category=“Confidential” ANDdocument.name=“//iserver1/user/**”’, or ‘message.from =NOT Employee ORmessage.to < >“*@partner-company.com”’), or both.

A resource may have a name and a number of attributes. The resourceexpression may cover any type of information including files, e-mail ordata object. Information may also be referred to as a resource. A fileis a common resource object. File resource expression may contain: (1)Directory, file path, file name, uniform resource identifier (URI), oruniform resource locator (URL). An expression may contain wildcardcharacters or other patterns defined by a regular expression. This maybe referred to as a resource name pattern. An example is“//server1/user/**” which potentially has more than one file orresource. (2) File system attributes. Common attributes include size,timestamps, owner, and type.

(3) Embedded file attributes. These are attributes shown in fileproperty dialog in Windows. They are embedded in Microsoft Officedocuments. Some common attributes are author, title, and description.Other embedded file attributes include Windows COM structured storageproperties, Adobe PDF file properties, HTML header and meta data tags,XML meta tags and custom tags designed to carry document properties andMIME header elements. (4) Extended file system attributes. These arefile system specific attributes. (5) Derived attributes. These areextended attributes in a specific embodiment of an information system ofthe invention.

(6) User input data. These are our extended attributes that store userclassification data. (7) Content filtering attributes. These are ourextended attributes generated through content analysis. (8) Contentclassification attributes. These are our extended attributes generatedthrough content analysis.

E-mail has its own attributes including to, from, cc, bcc, and subject.E-mail is among the types of information covered by the system. Dataobject attributes are application specific.

The event element (or ON element) in the policy language specifies alist of actions, exceptions, scheduled events, internal events, andexternal events.

An event expression may include any of the following:

(1) Action, which is produced by an interceptor which may interceptinside an application, at operating system, at network protocol driver,and at system device driver. Action can also be provided by applicationprogram logic in an authorization process. Common actions for documentcontrol and application usage include OPEN/READ, WRITE, DELETE, MOVE,COPY, PASTE, SEND, and ATTACH. Actions for network access controlincludes ENABLE, DISABLE, LOAD, UNLOAD, SEND, BLOCK, HTTP-GET, HTTP-PUT,and HHTP-POST.

(2) Scheduled event, which is generated by a scheduler when a time basedevent matures. Scheduled event can be used in handling tasks such asdocument retention. For example, a document retention policy may runperiodically to delete all documents that are older than three months.

(3) Internal event, which includes event generated by the managementsystem as a result of policy evaluation or activity data analysisprocess. For example, that activity data analysis process may havedetected some abnormal behavior and issues an internal event to acentral decision process to take further action.

(4) External event, such as an event sent by an external applicationthat integrates with the system of the invention

The subject element (or BY element) specifies a logical expression thatdescribes one or more subjects. Examples of some subjects include users,user groups, the role of a user, a user's business function, devices (orhosts), groups of devices (e.g., “file servers” or “finance departmentcomputers”), types of devices (e.g., laptop or PDA), applicationprograms (e.g., “Microsoft Word”), groups of application programs (e.g.,“Microsoft Office” or “Operating System Utilities”), types ofapplication programs (e.g., spreadsheet, instant messenger, or Webbrowser), or others.

A subject expression may include one or more of the following: (1) Userand user group. This information is typically obtained from an LDAPserver. (2) Host, which includes information about client computers,servers, personal digital assistants, smart phones, storage devices, andnetworking devices. (3) Application, which includes server applications,desktop applications and embedded application modules. Applications arethe software packages that can be managed.

The context element (or WHERE element) is a logical expression (orcontext expression) that describes the context this policy applies to.The context expression can include any logical combination of: resourceelements, action elements, subject elements, time (e.g., point in time,time of day, or day in the week), locations (e.g., “Main Office,”“London Office,” “Building H,” or “Home”), connectivity (includingaccess mechanism and bandwidth; e.g., WLAN, LAN, VPN, ISDN, Internet,DSL, Bluetooth, dialup, remote desktop protocol (RDP), virtual networkcomputing (VNC) protocol, latency, 56 kbps, broadband, 100 Mbps, and 1Gbps), policy directives (e.g., POLICY-ENFORCER-AT-POU orMSEXCHANGE-5.5), historical data, statistical data, data produced byanalyzing events, data provided by an external data source, and more.

Context expression may include one or more what can be referred to aspolicy context term or circumstance under which the policy is intendedfor. Some examples of policy contexts include: (1) Time, includingpoint-in-time, range, and periodic, such as time of day, day in week,day in month, day in year, week in month, and month in year. (2)Location. (3) Organization unit. (4) Access, such as LAN, WLAN, VPN,Internet, DSL, Bluetooth, bandwidth, and Internet Protocol (IP) address.(5) Directive, including an agent running at destination or destinationagent capabilities, or both.

A context element describes a circumstance that a policy is intended for(or a positive policy consequence (described below) should apply). Itworks in conjunction with resource element, action element and subjectelement to define a policy premise (or condition). For example, acontext element may describe a time period in which a policy should beapplied (i.e., adopting a positive policy consequence when other logicalpolicy elements are evaluated to true). In another example, a contextelement describes a policy that should be applied only if a workstationaccesses a server through virtual private network (VPN).

In a more complex example, a context element describes the logicalcombination of: (1) a user who is an employee; (2) a workstationconnected to a network at a branch office; (3) the user is using abrowser to access a secure server via secure sockets layer (SSL) VPN;(4) the access occurs during office hour; (5) the access occurs within asilent period before his (or her) company's quarterly financial resultis published; and (6) there is at most three users connected to thesecure server. This example illustrates that a context element can beused to describe a complicated circumstance. In some cases, a contextelement may specify one or more policy engine directives includingPOLICY-ENFORCER-AT-DESTINATION.

The positive consequence element (or DO element) includes a positiveconsequence statement. A positive consequence statement contains apolicy effect (e.g., ALLOW, DENY, query user, custom effect handler, andDELEGATE), optionally one or more obligation tasks, and optionally oneor more remediation tasks. A positive consequence is adopted duringpolicy evaluation when a policy's premise is evaluated to true.

The negative consequence element (or OTHERS element) includes a negativeconsequence statement. A negative consequence element has the samestructure as the positive consequence statement. A negative consequenceis adopted during policy evaluation when a policy's premise is evaluatedto false. Negative consequence is optional in a policy. When a negativeconsequence is not specified, a default negative consequence is usedwhich contains a policy effect which is the negation of the positivepolicy effect found in the policy.

In addition, a policy rule can also contain directives that provideinstructions to a policy engine (e.g., a policy engine in a policyenforcer or a policy engine in a policy decision server) to assist inpolicy evaluation and provide instructions to policy deployment module(typically a part of a policy server) to assist in policy deployment.Policy directives can appear anywhere in the policy, including withinthe policy elements described above. For example, a policy can containone or more collaborative directives (e.g., POU:<action> which describesaction information available at a point-of-use agent associate with apolicy evaluation request, or POLICY-ENFORCER-AT-DESTINATION).

In a specific implementation, the policy language allows policies to bespecified without hard coding physical resources (such as“C:\mysensitivedata\legaldocs\**”).

Referring to the table below, there are three different types of systemsconcerning how rules, decision making, and enforcement are managed. Thepolicy language of the invention may be applicable to any of the systemtypes I, II, or III, or in other system types. In the three systems,policies are designed to be centrally managed. For example, referring toFIG. 5, the rules may be managed using the policy server and held in thepolicy repository. In the three types of systems, there will bedistributed enforcement. For example, referring to FIG. 5, there aredistributed policy enforcers at the workstations and servers.

System Type Rules Decision Enforcement I Centralized CentralizedDistributed II Centralized Distributed Distributed III CentralizedHybrid Distributed

Decision making in the type I system is centralized. Then when adecision is needed as to whether a policy is satisfied, the decision orpolicy evaluation will be made by the policy server, policy decisionmaking server, or using another centralized technique. In a centralizedpolicy decision scheme, only one or a cluster of policy decision makingservers need to access a policy repository or having policies deliveredto the one or cluster of policy decision making servers. The serversresponsible for making policy decision are typically dedicated serversand the number of servers involved is typically relatively small.

In a type II system, the decision making is distributed, so a programrunning on the device (e.g., workstation or server) will make adecision. This is a system as shown and described in connection to FIG.5. Distributed policy decision scheme typically supports a large numberof policy decision points and requires policies distributed to eachpolicy decision point. In some implementation, either a centralizedpolicy repository or a collection of distributed policy repositories canbe used instead of having policies distributed to each policy decisionpoint. If distributed policy repositories scheme is used, any standardobject-based, file-based and database replication technique can be usedto synchronize the repositories. In additional, a distributed policyrepositories scheme may also maintain no master repository, one masterrepository or multiple master repositories. In a system that implementsdistributed policy decision, a policy decision point and one or morepolicy enforcement points are typically components of an applicationprogram resided on the device being managed.

On the other hand, a policy decision point may reside in a processseparated from a policy enforcement point on the same device or onseparate devices. In a type III system, the decision making is a hybrid,which means at times decision making is neither centralized nordistributed. In a hybrid decision making scheme, one policy decisionpoint can collaborate with at least one other policy decision point tocomplete a policy decision request.

For example, a hybrid decision making system may include one of thefollowing collaborative processes: (1) A distributed policy decisionpoint (i.e. on a device) communicates with another distributed policydecision point to complete a policy decision request. (2) A distributedpolicy decision point communicates with more than one distributed policydecision points to complete a policy decision request. (3) A distributedpolicy decision point communicates with a centralized policy decisionpoint to complete a policy decision request. (4) A centralized policydecision point communicates with a distributed policy decision point tocomplete a policy decision request. (5) Any combination of one or morecentralized policy decision points and distributed policy decisionpoints may be used. Not all decision making under the hybrid policydecision scheme need to involve more than one policy decision point,only some of the decisions require collaborative efforts.

The above table of system types gives some examples of informationmanagement systems. Some systems include policy enforcers or agents.Some systems may not have a policy engine in a policy enforcer (oragent); these systems would have centralized decision. A system may havea server system with many thin clients or Windows terminals. The policylanguage is applicable to systems with centralized decision.

Although not listed in the above table on system types, other systemsmay have centralized enforcement. The policy language of the inventionmay be applied to systems with centralized enforcement. Other systemsmay have hybrid enforcement, where part of enforcement mechanism isperformed using, for example, a desktop computer, and another part ofthe enforcement mechanism is performed using a centralized device, suchas a server.

Obligation refers to tasks related to a trigger (i.e., the task at hand)that a policy engine is obliged to complete. For example, commonobligations include: (1) Archiving an e-mail message. An application ofsuch is regulatory compliance where all executive e-mail communicationshould be archived. (2) Sending notification, such as when a criticaldocument is being accessed, then sending an e-mail to a documentadministrator. (3) Encrypting message before transmission. Theapplication can be security or regulatory compliance. HIPPA requirescertain communications to certain people be encrypted. (4) Altering amessage. Some export control rules requires e-mail messages be tagged atsubject line. Legal communication often includes message trailer.

Remediation refers to tasks not directly related to current triggerought to be carried out. Remediation tasks can be just about anything.For example, common remediation tasks include: A user has change jobwithin a company recently. The documents that a user was authorized toaccess may not be appropriate in the new job anymore. If some of thosedocuments have been copied to a user's laptop computer, it is mostdesirable to have those documents deleted. A remediation task can bespecified in a policy to take care of such action. The policy thatspecifies the remediation action can be triggered either through a jobchange event, a scheduled event that runs periodically, or when userfirst access a document the user is no long authorized access.

Below is an example of a policy. This policy or rule is for documents ina category with a “sensitive” attribute.

FOR document.category = “Sensitive” ON OPEN BY user = Executives, LegalDO ALLOW OTHERS DENY

For the above policy, when a document or information is denoted assensitive and that document or information is opened, and the user is anexecutive or legal (which are abstractions defined elsewhere), they willbe allowed to open. The system will deny others who are not members ofthe executive or legal group. These people will not be allowed to openthe sensitive document. In a specific implementation, for example, apolicy enforcer traps the open operation and prevents the open fromoccurring. The user may receive an error message that they are notpermitted to access or open the information because they are not in theappropriate group.

The above policy also includes some abstractions: executives, and legal.An abstraction (which may also sometimes be referred to as a variable)may be an expression including a string, integer, floating point,character, or Boolean, or combination of these. An abstraction may alsouse a further abstraction. For example, a policy may use a firstabstraction or variable, and an expression of the first abstraction orvariable has a further second abstraction of variable. In such afashion, one abstraction may chain or link to any number of furtherabstractions. A definition of the above abstractions is provided below.

Executive := <all users under LDAP group “vice-presidents”>, jthomas,tmichelle; Legal := <all users under LDAP group “legal”>;

The above policy is not fully represented using abstraction. It can berewritten as follow to take full advantage of abstraction. Forillustration purpose, the rewritten policy is also expanded to includeadditional groups of documents that are classified as sensitive.

FOR document = Sensitive ON OPEN BY user = Executives, Legal DO ALLOWOTHERS DENY Sensitive := Legal-Docs OR Financial-Reports ORdocument.name = “//server345/merger-and-acquistion/**” ORdocument.category = “Sensitive”; Legal-Docs := “//server-legal/**”Financial-Reports := “//server-finance/reports/**” OR“//server169/finance/shared/reports/*.pdf”

An abstraction is typically not defined within the policy itself. In anembodiment of the invention, policies and abstractions maintainedseparately. Policies and abstractions may be stored in a databasestructure. They may be in the same database or different databases. Thepolicies and abstractions may be stored in database tables. For example,policies may be in one table of a database and abstractions may be in asecond table of the database. On the other hand, policies andabstractions can be stored in one or more files.

There are benefits to providing a policy language which provides forpolicy abstractions. Policies and abstractions may be built separatelyfrom each. Policies and abstractions may be built by the same person orgroup of people. However, by separating policies and abstractions, thismakes it easier for different groups or people in an organization to beresponsible for one or the other. One group or person, who may bereferred to as a policy author or policy analyst, may modify a policywithout being concerned about the details of an abstraction, which ismaintained by another person, who may be referred to as a informationanalyst.

One may refer to the group responsible for policies as the policyinformation systems (IS) group and the group responsible forabstractions as the abstractions information systems group. Oneresponsible for policy abstraction may be referred to as an informationanalyst. Both policy analyst and information analyst use a userinterface module to compose policy and define abstraction. The userinterface may have two or more modules or configured to work differentlyfor the two classes of users. The policy information systems group canfocus on policies while the abstractions information systems group canfocus on abstraction.

Furthermore, an abstraction may be used in one or more policies. Andwhen a particular abstraction is changed, then the policies that referto or use that abstraction will also be changed. For the above example,if there are some new vice presidents in a company, a change is made tothe executives abstraction to include the new users. No policies need tobe changed. Once the executives abstraction is redeployed, all thepolicies (e.g., two, three, four, five, twenty, thirty, or more) thatreference the executives abstraction will be updated to include the newvice presidents. In such a way, this allows more effective and efficientmanagement of the information management system.

An example of a benefit of the policy language of the invention ishaving one policy written that can be applied by different types ofpolicy enforcers to perform different task. The policy language is ahigh-level policy definition language where the policy writer need notworry about lower level details. This is another benefit of abstractionand how rules are deployed (i.e., late binding).

For example, a policy may say that only an owner of sensitive documentscan copy such documents. This policy can be translated into:

(1) For a Windows Explorer interceptor (i.e., policy enforcer), the copyoperation is intercepted, evaluated, and enforced.

(2) For DOS command prompt, the shell command “copy” is intercepted,evaluated, and enforced.

(3) For Microsoft Outlook, the operation of copying an e-mail andforwarding an e-mail are intercepted, evaluated, and enforced.

(4) For a FTP Client, the operation of uploading a file is intercepted,evaluated, and enforced.

(5) For a Web browser, the operating of uploading a file is intercepted,evaluated, and enforced.

(6) For a file server, the operation of copying a file is intercepted,evaluated, and enforced.

(7) For Microsoft Exchange Server, the operation of copying an e-mailand forwarding an e-mail are intercepted, evaluated and enforced.Therefore, the policy writer can draft a relatively simple policywithout worrying about how each different policy enforcer will do itswork. The different policy enforcers will enforce the policy correctly.

For example, a policy may not be applied to all policy enforcers. Apolicy writer does not need to know this because the deployment steptakes care of deploying to the appropriate policy enforcers. Forexample, an e-mail message policy may only need to deliver to policyenforcers that handle e-mail. That means a file server that does nothandle e-mail will not need to receive such policies.

As a further example, a policy may be written for a specific e-mailserver or a particular application program version. A user should knowthe specific application of the policy, but does not need to know howthe policy will be deployed. The deployment step takes care of this.

FIG. 14 shows a functionality diagram of some modes of operation of aninformation management system of the invention. The modes are merelyexemplary and there may be many more modes in a system than what isshown. Some of the modes shown may be incorporated within one functionalor operation mode.

In a step 1301, policies or rules and abstractions are built. These maybe built by users coding the rules and abstractions or may beautomatically generated using policy or abstraction tools. For example,rules and abstractions may be created using an editor or graphical tool.

A step 1302 is a deployment mode of operation. In this mode ofoperation, the policy server will send the policies or rules to thedevices, workstations, servers, and others. In an embodiment, the entireset of policies may be transferred to each device. However, in a otherembodiments, a subset of the policies may be transferred to each device.A process called binding may be used so the policies or rules are boundor associated with a device or user (via a user name or user ID).

Deployment may include creating a delta, optimization, transformation,or translation, or combinations of these. These are discussed in moredetail below. In brief, creating a delta is a technique wheredifferences are sent to a target instead of a entire new set ofpolicies. Optimization is improving the efficiency in terms of space andexecution speed of a set of policies. Transformation is changing fromone format to another format, such as ASCII to binary, or rules tolook-up tables, or other. Translation is changing from one language toanother, such as from the policy language of the invention to a firewallpolicy language.

During binding, the policy server determines a set of rule andabstraction components relevant to a target device or target user (e.g.,a workstation component), and transfers this set of rule and abstractioncomponents to the target. Typically, a target has more limited storagecapacity (e.g., less memory, less hard disk space, and so forth) than aserver of the information system. For example, the target may be adesktop computer, notebook computer, PDA, smart phone, or other deviceor means by which a user connects to the system. Binding generallyreduces the amount of storage needed to store the policies on aparticular device.

A specific embodiment of deployment uses late binding. Late bindingassociates a subset of the policies or rules to a particular device oruser when that device or user is connected to the system. A custom setof rules is sent to the device (or user) when it logs in or connects tothe system. The set of rules is customized to the device (or user). Thisdevice may be a server, desktop computer, notebook computer, smartphone, or other. In an embodiment, when a device connects to theinformation system of the invention, the device requests rules to besent. The system creates a subset of rules for the device and thentransfers this subset to the device.

The late binding technique allows policies to be deployed to a policyenforcer automatically without user intervention. In a specificimplementation, for example, a subset of policies is delivered to adesktop computer or other device every time a user logins. A policyenforcer delivers a user ID or username to the policy server. The policyserver performs partial binding resolution and optimization beforedelivering a policy bundle to a client computer. Note that it is notnecessary to perform complete binding resolution because resourcecomponents can bind to too many resources (e.g., files). Some bindingresolution tasks may be deferred to the policy enforcer.

In an embodiment, the system of the invention transfers or sends therules which are pertinent to the target. This reduces the amount ofpolicy data that needs to be transferred, and also reduces the size ofstorage space needed. Therefore, a subset of the policies at thecentralized policy server is transferred to the target. For example, ifuser A is logged in, then only rules related to user A will betransferred. Rules which do not affect or cannot be applied to user Awould not be relevant. And if user A is logged through a smart phonerather than a desktop computer, then rules concerning to user A and asmart phone would be relevant and transferred. For example, assuming thesmart phone does not have a word processing application, then rulesconcerning word processing (such as cut and paste) would not be relevantand would not be transferred.

In addition to late binding, there are other binding techniques, such asearly binding. Early binding refers to a technique where a subset ofrules are not necessarily customized for each device or user. In earlybinding, there may be a set of predefined target profiles. Any number ofpredefined target profiles may form a set. For example, there may bethree predefined target profiles with a three subsets of rulesassociated with these three target profiles. A first target profile maybe a desktop personal computer, a second target profile may be a server,and a third target profile may be a personal digital assistant or smartphone. When one of these devices connects to the system, the subset ofrules associate with this device will be transferred to the device.Compared to the above late binding technique, the subset of rules is notnecessarily as customized for each device since it has been predefined.

In early binding, a policy bundle associated with a policy profile canbe preassembled and stored on a policy server. The preassembled policysubset can be delivered to a device via a network or a removable storagemedium.

In further embodiments of the invention, other types of binding may beused, such as a combination of early binding and late binding. There maybe binding where rules are dynamically pushed to the device whenever achange in the rules occurs, at scheduled times, or when a certain eventoccurs. Any of these binding techniques may be used in an informationmanagement system of the invention.

An advantage of binding (early or late) is that a subset or smaller setof policies is deployed. Deploying a smaller set of policies—instead ofthe complete set of policies, many of which may be irrelevant to aparticular device—reduces the storage space required to store thepolicies on the device. Also, with fewer policies, the device making thedecision during an execution mode 1303 can resolve the set of policiesmore quickly because there are fewer policies to evaluate.

Policy subsets created in the deployment mode are typically organizedinto policy bundles. A policy bundle may comprise of a subset ofpolicies, a subset of policy abstractions that the set of policiesdepends on, and configuration and supporting data that is required toevaluate the subset of policies and policy abstractions.

In an embodiment, during deployment, a system may deliver a delta of thesubset of policies and policy abstractions. A delta is formed by firstcreating a policy subset (including policy abstractions) on the policyserver based on information in a target profile. Obtain information onwhat policies and policy abstractions are available at the target(discussed later). Using the subset and information on policies andpolicy abstractions on the target, generate a difference list and shipthe different list to the target. At the target, use the different listand the set of policies and policy abstractions available locally torecompose the policy subset that is meant for the target.

There are many different ways to create a delta, and any of these may beused. One way is the target ships the policy server about what policiesand policy abstractions it has on the target. The other is a policyserver maintain a list of policies shipped successfully to the target.Yet another way is the policy server asks the target for a list. Any oneof these method can be further simplified by labeling (or numbering) thepolicies and policy abstractions and versions of policies and policyabstractions so that a policy or an abstraction can be identifiedeasily. Say, using a labeling solution, the policy server can get a listof policy labels form the target upon successful connection and maintainsuch list at the policy server. Subsequent transmission of policy willbe done by comparing a policy labels with the list of labels. A list ofdifferences can be shipped to the target for reconstruction.

In another embodiment, a system may deliver a subset of policies basedon a partial target profile and then merge the result with existingpolicies on the target. A typical example for this case is when a userlogs in. We get policies associated with a user and not policies for aworkstation. Once user-related policies arrive at a workstation, thepolicies are merged with existing policies relevant to the workstation.

In another embodiment, the system can perform push or pull delivery.Push delivery is initiated by the policy server to where policy engineis located. Normally, push is a result of implementing a user request ofimmediate policy delivery, an activity data analysis process generatesan internal event to implement some urgent policies, or a policy on apolicy server is invoked through delegation by a policy enforcer thattriggers immediate policy delivery.

Pull delivery is initiated by a policy enforcer to a policy server toask for new policies. Typical examples are when at system boot up orconnection to the network, a device will ask the policy server if thereare any new policies for the device. The policy server may respond witha set of new policies to add to or replace one or more existing policiesat the device. Another example is when a user logs on. A user may notuse that particular workstation before, so the workstation contains nopolicy specific to that user. Therefore, the policy enforcer on theworkstation should acquire policies relevant to the user so that it canapply the correct set of policies to the current user.

Policies may be delivered in a different format based on capability of apolicy enforcer or policy engine in a policy enforcer. For example, wecan deliver policies in binary format to a cell phone and deliverpolicies as a partially optimized look-up table for desktop and laptopin text format.

Policy deployment may be applied to system that supports policies alone,policy abstractions alone, and policies plus policy abstractions. Anembodiment of the invention may deploy policies only with policyabstractions fixed. An embodiment of the invention may deploy policyabstractions only with policies fixed. An embodiment of the inventionmay deploy configurations only.

Policy selection may be done with policy abstractions and policies orrules at the same time. In a specific implementation, selection ofrelevant policy is done in the following steps:

(1) In a first step, inspect all policies and place all relevant policesin a first list.

(2) In a second step, inspect all policy abstractions and place allrelevant policy abstractions in the second list.

(3) In a third step, find all policy abstractions not in the second listthat reference at least one policy abstraction in the second list andadd them to the second list. Repeat this step until no more policyabstraction having a reference to a policy abstraction in the updatedsecond list can be found.

(4) In a forth step, find all policies having a reference to a policyabstraction in the second list and place them in the first list

(5) In a fifth step, find all policies having reference to a policy inthe first list and add them to the first list. Repeat this step until nomore policy having a reference to a policy in the updated first list canbe found.

Below is a list of some of the factors which may be used in thedeployment mode to determine whether a rule is relevant or not. When arule is considered relevant, the rule and all policy abstractionsreferenced by the rule and all supporting configuration and data will betransferred to the target.

(1) Who is the user? Then, rules relevant to the user may betransferred.

(2) Who are the users active on this machine? For example, a MicrosoftWindows 2003 Terminal Services can have many users on it. This may be anadditional consideration in determining whether a rule is relevant.Rules relevant to the users may be transferred.

(3) What group does this user belong to? For example, the user may be amember of a group such as accounting, legal, engineering, executive,vice president, board of directors, quality assurance, assembly,production control, fabrication, patent, information services, humanresource, or another group. This may be an additional consideration indetermining whether a rule is relevant. Rules relevant to the group orgroups the user belongs may be transferred.

(4) What type of machine is this? The machine or device may be, forexample, a laptop, desktop, PDA, smart phone, terminal server,information kiosk, or other device. This may be an additionalconsideration in determining whether a rule is relevant. Rules relevantto the machine or device may be transferred. For example, there may be apolicy just for laptop or PDA.

(5) What group does this computer belongs to? For example, the computeror device may belong to the finance department, engineering, guest,human resources, and so forth. This may be an additional considerationin determining whether a rule is relevant. Rules relevant to the groupthe computer belongs to may be transferred.

(6) Is the target a server machine or a client machine? There may bepolicy specific for all server machines and some for all clientmachines. These may be additional considerations in determining whethera rule is relevant. Rules relevant to servers or clients, or both, maybe transferred.

(7) What type server application is running on this machine? Forexample, the server may be running an application such as a mail server,Microsoft Exchange Server, Microsoft SharePoint Portal Server,Documentum server, CRM server, database server, and so forth.Furthermore, there may be a specific policy for all mail servers whetherit is a simple SMTP server or a Microsoft Exchange Server. There mayalso be a policy just for Microsoft Exchange Server because Exchange isdoes so much more than other mail servers. This may be an additionalconsideration in determining whether a rule is relevant. Rules relevantto the type of server application running on the machine may betransferred.

(8) What type of application is running on the client machine? Forexample, the application may be instant messenger (IM), mail client, Webbrowser, Yahoo Messenger, Microsoft Outlook, Microsoft InternetExplorer, Mozilla Firefox, Microsoft Word, Microsoft Excel, MicrosoftWindows Explorer, DOS prompt, ksh, csh, FTP client, and so forth. Somepolicies may be written for a class of application such as instantmessenger. Other policies may be specific to a particular applicationlike Microsoft Outlook. This may be an additional consideration indetermining whether a rule is relevant. Rules relevant to theapplication running on the client machine may be transferred.

(9) What version of software or operating system (OS) is running at thetarget? For example, for Microsoft Office, there many versions includingMicrosoft Office 97, Microsoft Office 2000, Microsoft Office XP, andMicrosoft Office 2003. The operating system may be Windows 95, Windows2000, Windows XP, Windows Mobile, Microsoft Vista, Linux, Ubuntu,Macintosh OS X, or another. There may be policies based on softwareversions. One release of some software may be significantly differentfrom another release, and a policy can be tailored for a specificversion. These may be additional considerations in determining whether arule is relevant. Rules relevant to a version of a particular softwaremay be transferred. Rules relevant to an operating system may betransferred.

(10) What scope does the policy need to execute? Multievent policy andcorrelation policy may be applied at point of use (POU) (i.e., a clientcomputer), server, policy server, or any server dedicated to performpolicy evaluation. Therefore, there may be a directive in a policy totell where the policy belongs. Policy can also be inspected to identifywhere it should be deployed based on resources and other specifications(such as directive) in the policy. This may be an additionalconsideration in determining whether a rule is relevant. Rules relevantto a scope of the policy may be transferred.

(11) Where is the user logging in from and what type of connectivity isused to make the connection? For example, the user may be logging inwhile in the office, branch office, home, using virtual private network(VPN), via wireless LAN, using secure or nonsecure site connection, orusing a connection with a particular bandwidth. These may be additionalconsiderations in determining whether a rule is relevant. Rules relevantto where the user is logging in from may be transferred. Rules relevantto what type of connectivity or bandwidth the user is connecting withmay be transferred.

(12) What is the capability of a device? For example, can the devicesend e-mail? Can any document be saved on the device? Can the deviceconnect to a printer? These may be additional considerations indetermining whether a rule is relevant. Rules relevant to the capabilityof the device may be transferred.

For deployment, when determining relevancy, in specific embodiments ofthe invention, a device's capability may be used to (i) determinerelevancy, (ii) determine if certain type of resource is on a device,(iii) determine if certain event can happen on a device, and others.

Further during the deployment step, there may be further optimizationsbefore the policies are deployed or transferred to the devices. This maybe during the deployment step or in a separate optimizations step. Forexample, as an optimization step, part of a policy can be preevaluatedduring policy binding. For example, for policies deployed to clientagent where a user is known, LDAP groups can be resolved during policybinding therefore eliminating some subexpressions in a policy. Theoptimized policies may be considered modified policies since they havebeen altered compared to the original policies. The modified policieswill be logically equivalent to the original policies which they arebased on.

One optimization technique may be used is constant subexpressionfolding. For example, in the expression for a policy, there may beportions of subexpressions of the expression where the result is known,and hence are constants since they are not variable. Therefore,subexpressions can be replaced with a constant or removed from theexpression. Since the decision-making device need not evaluate theseconstant subexpressions, execution time is reduced and memory space issaved. In an implementation of the invention, during the deployment modeor in an optimization mode, the constant subexpressions are replacedwith a constant or removed before transferring the policies to thetarget.

Furthermore, in a specific technique of invention, a subset of rules andabstractions may be modified by removing a subexpression of a rule whenthe subexpression evaluates to a Boolean true. In particular, when thesubexpression is an AND term of a larger expression, when thesubexpression evaluates or is otherwise determined to be a Boolean true,this AND term does not affect an outcome of the larger expression. Sothe subexpression may be removed.

Similarly, a subset of rules and abstractions may be modified byremoving a subexpression of a rule when the subexpression evaluates to aBoolean false. In particular, when the subexpression is an OR term of alarger expression, when the subexpression evaluates or is otherwisedetermined to be a Boolean false, this OR term does not affect anoutcome of the larger expression. So the subexpression may be removed.

In the alternative to the above, the subexpression may be replacedinstead of being removed. For example, the Boolean true subexpressionmay be replaced with a representation of a Boolean true, such as a 1.The Boolean false subexpression may be replaced with a representation ofa Boolean false, such as a 0. Or the subexpression may be replaced withwhatever constant value it is evaluated to be, such as a mathematical orother subexpression, that evaluates to a constant such as 32.

Some specific optimization techniques include (1) common subexpressionelimination, (2) constant folding, (3) constant propagation, (4) deadcode removal, (5) comparison optimization, and (6) redundant policyelimination. These are discussed in more detail below. Any of theseoptimization techniques may be used in the information management systemof the invention, and in any combination.

A step 1303 is an execution mode of operation. In this mode ofoperation, the code component of the workstation manages access toinformation or devices of the information management system based on theset of rule and abstraction components. These devices may includecomputers, fixed disk drives, servers, personal digital assistantdevices, or telephony devices.

In a step 1304, the rules and abstractions may be modified. The rulesand abstractions may be modified independently of each other. Forexample, one or more abstractions may be modified while the rules remainunchanged. Or one or more rules may be modified while the abstractionsremain unchanged.

The rules or abstractions, or both, may be modified at any time. Whenthe rules or abstractions, or both, are modified after they aredeployed, the system will redeploy the changed rules or abstractions. Ina specific implementation, the changed rules or abstraction, or both,are redeployed in real time. In particular, after changes are made tothe rules or abstractions, the deployment mode is entered into. Afterredeployment, in the execution mode of operation, the new rules orabstractions, or both, will be in effect. This feature of theinformation system allows a user to customize and redeploy rules whilethe system is in operation.

There may be a heartbeat connection between the policy enforcers and thepolicy server (or other server such as a communication server). Theheartbeat connection may not be direct to the policy server but may bethrough another server such as the communication server. Via theheartbeat connection, the policy server can tell which policy enforcersare connected to the system. So, when one or more policies are updatedor altered in some way, the policy server will know which devices toredeploy the new policies to. For example, when the heartbeat connectionis broken between a laptop computer and the policy server, the policyserver will know that redeployment of policies does not need to be doneto the laptop computer. The heartbeat connection may be updated aperiodic time intervals, such as every few seconds, five seconds, tenseconds, and other intervals.

In further embodiments of the invention, the heartbeat connection mayalso be used for other functions including sending log data from apolicy enforcer on a device to an intelligence server. The heartbeatconnection may not be direct to the intelligence server, but throughanother server, such as the communication server.

FIG. 15 shows an example of interactions between multiple policies andmultiples policy abstractions and their interaction. There are twopolicies or rules 1401 and 1402. Rule 1401 has an abstraction“Highly-Sensitive” that references a policy abstraction“Highly-Sensitive” 1403. Rule 1401 further has an abstraction “Contract”that references a policy abstraction “Contract” 1405. Rule 1402 has the“Highly-Sensitive” abstraction that also reference policy abstraction“Highly-Sensitive” 1403. Rules 1402 has an abstraction “Sensitive” thatreference a policy abstraction “Sensitive” 1404.

This figure shows the decoupling of policies and abstractions of thepolicy language of the invention. A rule may include any number ofabstractions. In fact a rule need not include any abstractions, but byusing abstractions, this provides advantages. The first rule has twoabstractions and the second rule has two abstractions.

The first rule and second rules each share one abstraction,“Highly-Sensitive.” The “Highly-Sensitive” may be modified, for example,to include additional documents or information. When the first andsecond rules are redeployed at one or more targets (such as when a userlogs in at a machine), the updated rules with the new “Highly-Sensitive”definition will be transferred to the target. This is an importantfeature because two or more policies (and perhaps tens, hundreds, oreven thousands of policies) may be modified without making changes toeach policy itself. For any policy administration staff, this is asubstantial time saver.

The “Contract” abstraction may be modified and will affect the firstrule without affecting the second rule. The “Sensitive” abstraction maybe modified and will affect the second rule without affecting the firstrule.

FIG. 15 shows an example of one policy and multiple policy abstractions,where one policy abstraction references other policy abstractions. Thereis a first rule 1501 that references a policy abstraction“Highly-Sensitive” 1502. The “Highly-Sensitive” abstraction references a“LegalDocs” abstraction 1503 and a “FinanceReports” abstraction 1504.The first rule further references a “Contract” abstraction 1505.

This example shows how a policy abstraction may refer to another policyabstraction. This may be referred to as a nested abstraction. Two levelsof abstractions are shown. The first level is from the first rule to“Highly-Sensitive,” and the second level is from “Highly-Sensitive” to“LegalDocs.” For example one of the second level abstractions may referto a third level, and so forth. Each abstraction may be built on anynumber of levels of abstraction, two, three, four, five, six, seven, andeight or more.

An abstraction may reference any number of abstractions itself. Here,“Highly-Sensitive” has two abstractions, but there may be one, or morethan two, such as three, four, five, six, seven, or eight or more. Alsoa policy may have any number of abstractions, one, two, three, four,five, six, seven, or eight or more.

In a policy, an abstraction may be used in any of the resourceexpression, event expression, subject expression and context expression.In the above examples, abstractions are used in resource expressions andsubject expressions in the policies.

FIG. 17 shows accessing confidential document, seeking approval, withcentralized decision. An information system is show in the figure. Thereis a policy server 1601 in an organization which accesses a policyrepository of policies or rules. The policy repository may be part ofthe server or separate from server, such as part of another server orspread across multiple servers. There is a user 1603 in an organizationlogged into a workstation 1602. The user attempts to access 1607 aconfidential document on a document server 1604. The confidentialdocument is stored in a document repository 1605. A policy enforcer 1606installed on the document server seeks approval 1608 for the requestedoperation from the policy server. The policy server returns “notgranted” 1609 to the document server. The policy enforcer in thedocument server denies 1610 user access to the document.

In FIG. 17 and elsewhere in this application, we refer to a document asa confidential document. This means that the document has one or moreattributes to identify the document is classified as confidential,meaning it is not accessible by every user. In this patent, aconfidential document is document with at least some access controls, soit is not accessible by every user of an organization. In other words,for a confidential document, at least one user of an organization willbe denied access when this attempts to access the confidential document.In contrast, an open or nonconfidential document may be one where thereare no access controls and every user in an organization is allowedaccess. Furthermore, one or more attributes of a nonconfidentialdocument may be altered or set to turn it into a confidential document.

A document may be classified as confidential or other classificationbased on the document's attributes. These attributes may depend on orbased on factors such as a location of a server where the document isstored, directory in a file server where the document is stored, name ofthe file, type of the file, content classification type, attributesdefined in a document management system and associated with thedocument, or a property embedded in the document or e-mail (e.g., e-mailfrom a CEO).

Furthermore, the information management system not only handlestraditional documents which may include files, but also handle e-mail,file store in document management system, and other as discussed in thisapplication.

FIG. 18 shows accessing confidential document, seeking approval, withdistributed decision. An information system is show in the figure. Thereis a policy server 1701 in an organization which accesses a policyrepository of policies or rules. The policy server distributes policies1707 to policy enforcers, of which a policy enforcer 1704 in an example.A document server 1705 has a policy enforcer running on it monitoringaccess to documents and enforcing policies (or rules).

A user 1703 in the organization logs into a workstation 1702 with policyenforcer 1704. The user tries to access 1708 a confidential document onthe document server, which is stored in a document repository 1706. Thepolicy enforcer detects the access operation. The policy enforcerevaluates policies distributed to it to determine if approval should begranted to the access operation. In this example, based on one or morepolicies, the policy enforcer decides not to grant access 1709 to thedocument and it enforces the decision by blocking the access attempt bythe user

FIG. 19 shows blocking sending of a confidential document outside thecompany. There is a first user 1802 in an organization accessing aninformation system of the organization through a workstation 1801. Thereis a second user 1805 outside the organization. The second user is on aworkstation 1804 and is connected to the Internet 1809. There is afirewall 1808 between workstation 1801 and the Internet.

The first user tries to send a confidential message 1810 to the seconduser. The workstation the first user used to send the confidentialmessage has a policy enforcer 1803 installed. The policy enforcer on theworkstation intercepts the send operation and seeks approval 1811 from apolicy server 1806. The policy server is connected to a policyrepository 1807 which holds the policies. The policy server decides notto grant approval 1812 to the send operation. The policy enforcerimplements the decision by blocking the confidential message from beingsent by the first user.

FIG. 20 shows encrypting a confidential document when copying to aremovable device. There is a user 1902 in an organization. The user islogged into a workstation 1901. The user tries to copy a confidentialdocument to a removable media 1904, such as a CD-ROM, DVD-ROM, floppydisk, smart phone, PDA, MP3 player, or USB drive. The workstation theuser used to copy the confidential document has a policy enforcer 1903installed. The policy enforcer on the workstation intercepts the copyoperation and seeks approval 1907 from a policy server 1905. The policyserver accesses a policy repository 1906 which holds the policies.

In this example, the policy server decides to grant approval 1908 to thecopy operation but require that the confidential document be encrypted1908 before placing on the removable media and this operation to belogged. The policy enforcer implements the decision by effectingencryption 1909 of the confidential document and allowing the copyoperation to complete, and recording the operation in an activity log.The activity log may be later used in correlation (discussed later).

The encryption process can be done in many ways. For example, policyenforcer can be equipped to perform encryption. However, there are alsodevices that can handle encryption automatically. Alternatively, filesystem such as NTFS can also handle encryption if a file attribute isset. Effecting encryption of the confidential document may be done by,for example, (1) a policy enforcer performing encryption, (2) a policyenforcer setting a file attribute to cause a file to be encrypted, (3) apolicy enforcer doing nothing because the device automatically encrypts,or (4) other encryption techniques.

FIG. 21 shows sending of a confidential document between users whoshould observe separation of duties. This type of policy for separationof duties is sometimes known as an “ethical wall” or “Chinese Wall,”which may be useful in preventing or managing potential conflict ofinterest situations. California Justice Harry Lowe has taken offense tothe phrase “Chinese Wall” and wrote an opinion at Peat, Marwick,Mitchell & Co. v. Superior Court 200 Cal. App. 3d 272, 293-294, 245 Cal.Rptr. 873, 887-888 (1988) (Low, Presiding Justice, concurring andsuggesting using “ethics wall” instead of “Chinese Wall”).

There are a first department and second department in an organization.Although in this specific example, the first department and seconddepartment are groups in the same organization, the first department andsecond department may be groups of different organizations or may beentirely different organizations themselves. And although twodepartments or groups are shown, such an ethical wall policy may beimplemented among any number of groups, including two, three, four,five, or more groups. Some of the groups may be in the sameorganization, while other groups are in different organizations oroutside an organization. The groups in the same organization may bemanaged by one information management systems or multiple informationmanagement systems.

The users in first department and second department are required toobserve separation-of-duty rules such that no exchange of confidentialinformation among users in first department and users in seconddepartment is allowed. This policy is illustrated as a firewall 2036between the first and second departments. There is a first user 2032 ona workstation 2031 in the first department. There is a second user 2035on a workstation 2034 in the second department. The first user tries tosend a confidential message 2031 to the second user.

The confidential message is sent through a mail server 2037. The mailserver has a policy enforcer 2038 installed. The policy enforcer on themail server intercepts 2042 the sending of the confidential message. Thepolicy enforcer seeks approval 2043 from a policy server 2039, whichaccesses rules in a policy repository 2040. The policy server does notgrant approval 2044 to the sending of the confidential message. Thepolicy enforcer on the mail server blocks the sending of theconfidential message.

When implementing separations of duty, the policies of the system mayblock a user from accessing to information of another group, blockconnections between users of two groups, or block access to applicationsbelonging to another group. Connections including instant messenger,peer-to-peer, voice-over-IP calls, and e-mail may be managed by thesystem. Applications or access such as through an FTP server, webserver, or file server may be managed by the system. Based on thepolicies, a user will be allowed or denied access to the information orresource the user requested.

The expressiveness of the policy language of the invention allowscomplex policies that depend on one or more resources, one or morepersons, one or more locations, time, connectivity, or any combinationof these, or others to be specified. In one application of the policylanguage, policies may be specified to create an information barrier(ethical wall or “Chinese Wall”) among groups of people (e.g., users orrecipients), among groups of devices (e.g., desktops or servers), amonggroups of application programs (e.g., mail servers or clients, instantmessaging servers or clients, voice over Internet protocol (VoIP)servers or clients, or FTP servers), or among groups of people andgroups of resources where complex relationships among people andresources such as mutually exclusive access to a resource may bespecified.

Policies designed to create an information barrier are typicallyimplemented in finance, legal, manufacturing, and other industries toprevent personnel in a company from carrying out tasks that may resultin a “conflict of interests” situation. For example in the financeindustry, security regulations often prohibit staffs in a trading groupof a company from exchanging information related to securities withstaffs in other product or service groups of the company.

Therefore, an information barrier needs to be created between thetrading group and other groups in the company. An example of themanufacturing industry, a contract manufacturer of technology productsmay serve two or more clients which compete in the same market. Thecontract manufacturer is responsible for protecting intellectualproperties, project plans, marketing and sales data and otherconfidential and proprietary information of each client. As a result,information barriers are erected among groups of employees working onproducts of different clients. The information barriers described in theabove examples may be implemented using policies based on the policylanguage described in the above.

In a centralized decision system, the decision may be made by a policyengine (or policy decision point) at a central server. In a distributeddecision system, the decision may be made by a policy engine residing onthe users device. A system may be a combination of centralized anddistributed decision making.

The following discusses binding in more detail. For the purpose ofillustration, the following examples show binding of one policy in thepolicy binding step (in a policy server). In practice, the binding stepcan select any number of policies, such as no policies, one policy, twopolicies, three policies, or four or more policies relevant to a target,one or more policy abstractions relevant to a target, one or more policyabstractions associated with the selected policies, one or more policiesassociated with the selected policy abstractions, or any combination ofthese.

FIG. 22 shows an example of late policy binding which occurs when aclient workstation 2001 request for policies after it starts up. Belowis a policy that successfully binds to the client workstation based on atarget profile provided by the client workstation. This example alsoillustrates the function of a “pull” mode of policy distribution.

FOR document.name = “*.doc” OR document.name = “*.xls” ON COPY BY user =Finance WHERE device.type = “workstation” ANDdestination.device.category = “portable” DO ALLOW AND ENCRYPT AND LOGOTHERS ALLOW

The simplified system described in this example includes a clientworkstation 2001 which has a policy enforcer installed 2002 and a policyserver 2003. In a step 1 (2005), the policy enforcer performs itsfunction at client workstation start up. The policy enforcer attempts tocontact the policy server in a step 2 (2006) trying to obtain an initialset of policies relevant to the client workstation or obtain a policyupdate. In the process, the policy enforcer provides the policy serverwith a target profile which includes information such as clientworkstation's host name, IP address, and other relevant information.

In a step 3 (2007), the policy server receives the request initiated bythe policy enforcer on the client workstation. The policy serverprocesses the request by selecting relevant policies from a policyrepository 2004. The selection process results in a subset of policiesmatching the target profile which may include zero, one, or more thanone policy. This selection process is called policy binding. Theresulting subset of policies and related support information together iscalled a policy bundle.

During the binding process, a policy server can make intelligentdecision on whether a policy is relevant to a target based on ananalysis of different elements in a policy combined with informationabout the target. For example, the binding process may identify a policyapplies to file access based on information specified in the policy'sresource element. At the same time, the target profile indicates thatthe target can only handle e-mail messages and calendar functions butnot file access. The binding process decides that such policy is notrelevant to the target. In addition, the binding process can also usedeployment directives entered by a policy author to determine if thepolicy relevant to the target.

This example assumes that the binding process resulted in the selectionof the above policy because the target profile specifies a device typeof “workstation” (the device type may be provided by the policy enforcerdirectly or by looking up information stored in a LDAP directory) andthe context element (or WHERE element) in the above policy specifies thepolicy applies to a workstation. In this case, the policy bundle createdby the policy binding process includes the above policy and informationrelevant to that policy.

In a specific implementation where a management system supports policyabstraction, the policy binding process includes selection of policyabstractions associated with the selected policies and policyabstractions matching the target profile along with other related policyabstractions and policies. The binding process may also produceadditional information relevant to support evaluation of the selectedpolicies and policy abstractions. In this case, the policy bundlecreated by the policy binding process includes a subset of policies, asubset of policy abstractions and all relevant information. The relevantinformation may include configurations and support data.

In a specific implementation where a management system does not requiredynamic distribution of policies, the policy binding process selectspolicies and policy abstractions matching a target profile and allpolicy abstractions being referenced. The binding process may alsoproduce additional information relevant to support evaluation of theselected policies and policy abstractions. In this case, the policybundle created by the policy binding process includes a subset of policyabstractions and all relevant information (where the selected policiesare excluded).

In a specific implementation where a management system does not requiredynamic distribution of policy abstractions, the policy binding processselects policies and policy abstractions matching the target profile andall policy abstractions being referenced. The binding process may alsoproduce additional information relevant to support evaluation of theselected policies. In this case, the policy bundle created by the policybinding process includes a subset of policies and all relevantinformation (where the selected policy abstractions are excluded).

If a policy bundle is produced in step 3, the policy server returns apolicy bundle to the client workstation in a step 4 (2008) along withany additional support information.

In a specific implementation, the policy server performs optimization onpolicies and policy abstractions produced by the policy binding processand transfer the optimized subset of policies and policy abstractions ina policy bundle to the client workstation. The optimized policies andpolicy abstractions may have the same policies format as thepreoptimized policies or may be transformed to a different policyformat.

In a specific implementation, the policy server performs optimization onpolicies produced by the policy binding process and transfer theoptimized subset of policies in a policy bundle to the clientworkstation. The optimized policies and policy abstractions may have thesame policies format as the preoptimized policies or may be transformedto a different policy format.

In a specific implementation, the policy server performs optimization onpolicy abstractions produced by the policy binding process and transferthe optimized subset of policy abstractions in a policy bundle to theclient workstation. The optimized policies and policy abstractions mayhave the same policies format as the preoptimized policies or may betransformed to a different policy format.

In a specific implementation, the policy server compiles a list ofdifferences between the subset of policies and policy abstractionsproduced in the policy binding process and the subset of policies andpolicy abstractions on the client workstation and transmits the list ofdifferences and other supporting information in a policy bundle to theclient workstation.

In a specific implementation, the policy server compiles a list ofdifferences between the subset of policies produced in the policybinding process and the subset of policies on the client workstation andtransmits the list of differences and other supporting information in apolicy bundle to the client workstation.

In a specific implementation, the policy server compiles a list ofdifferences between the subset of policy abstractions produced in thepolicy binding process and the subset of policy abstractions on theclient workstation and transmits the list of differences and othersupporting information in a policy bundle to the client workstation.

The client workstation receives a response from the policy server instep 5 (2009). If the policy binding process in step 3 produces a policybundle, the response contains a policy bundle. The subset of policies inthe policy bundle is enforced at the client workstation.

In a specific implementation, the policy bundle received by the clientworkstation replaces the subset of policies or policy abstractions, orboth, on the workstation.

In a specific implementation where multiple subsets of policies orpolicy abstractions, or both, are supported by a client workstationpolicy enforcer, the policy bundle received replaces at least one subsetof policies or policy abstractions, or both, on the client workstationor combine with at least one existing subset of policies or policyabstractions, or both, on a workstation.

In a specific implementation where a client workstation policy enforcersupports transferring a list of differences in a policy bundle, theclient workstation policy enforcer applies the list of differences inthe policy bundle received to at least one subset of existing policiesor policy abstractions, or both, to reconstruct the desired at least onesubset of policies or policy abstractions, or both.

For ease of explanation, the followings are not shown in the aboveexample: (1) policies not bound to the client workstation; (2) otherpolicies (in additional to the one shown above) that bind to the clientworkstation; (3) policy abstractions associated with the above policyand other policies bound to the client workstation; and (4) policyabstractions not bound to the client workstation.

An aspect of deployment is that code is inspected before it isassociated with a particular target. Code is associated to a targetbased on an inspection of the code. A target may be a device or a user.A number of code components may be inspected at one time and thentransferred or otherwise associated to a target based on the target'sprofile. A code component may be a policy of an information managementsystem.

In an implementation, the invention is a method including providing anumber of code components; providing a number of devices having deviceprofiles; and inspecting contents of the code components. The methodincludes based on a result of the inspection of the contents of the codecomponents and the device profiles, determining which of the devices toassociate a code component with.

The code component may be a policy or policy abstraction of ainformation management system. Further examples of a code componentinclude a statement, a statement having at least one expression, astatement having at least one variable, a script, an uncompiled Clanguage file, an uncompiled high-level programming language file, anASCII file, an expression, an expression having at least one variable, abinary file, and an executable file.

The associated code with a device may be transferred to the device. Ifthe code are policies, these will be the policies that are relevant tothe device and govern access to information via the device. Theassociated code may be altered in some way, such as optimized,translated, or converted to a different form. For example, theassociated code may have common subexpressions replaced beforetransferred the code to the associated device.

In an implementation, the invention is a system including a databasehaving a number of policies and a number of devices, each having aprofile. There is an inspection engine having executable code to causeinspection of each of the policies and executable code to determinebased on the result of the inspection and the profiles of the deviceswhich of the devices each of the policies will be associated with.

In an implementation, the invention is a system including a number ofcode files and a number of devices, each having a profile. There is aninspection engine including executable code to cause inspection of eachof the code files and executable code to determine based on the resultof the inspection and the profiles of the devices which of the deviceseach of the code files will be associated with.

In an information management system, relevant policies are deployed totargets while policies which are not relevant are not. By deployingrelevant policies, this reduces the amount of space requirements at thetarget to store the policies and the amount of data that needs to besent to the target. Also, execution speed at the target may increasesince the target does not need to evaluate policies that are notrelevant.

In an implementation, the invention is a method including providing anumber of policies, where the policies are applicable to a number oftarget profiles, each having a set of target attributes and analyzing apolicy to determine whether that policy is relevant to a specific targetprofile with a set of specific target attributes. The method includesdetermining a policy is relevant when a value of at least one of thespecific target attributes is used during an evaluation of the policy.The policy may include policy abstractions.

In an implementation, the invention is a method including providing anumber of policies, where the policies are applicable to a number oftarget profiles, each having a set of target attributes and analyzing apolicy to determine whether that policy is relevant or irrelevant to aspecific target profile with a set of specific target attributes. Themethod includes transferring relevant policies to a specific target withthe specific target profile and not transferring irrelevant policies tothe specific target.

Further in a specific implementation, the method may include when thespecific target attributes of the specific target profile changes,reanalyzing the policy to determine whether that policy is relevant orirrelevant; and retransferring relevant policies changes to the specifictarget with the specific target profile with the changed specific targetattributes. Alternatively, the relevant policies, not just the changesmay be transferred to the specific target.

Further, in a specific implementation, the method may includedisconnecting the specific target from a system and then subsequentlyreconnecting the specific target to the system; and after reconnectingthe specific target to the system, reanalyzing the policy to determinewhether the policy is relevant or irrelevant to the specific target.After reanalyzing the policy, relevant policies may be retransferred tothe specific target with the specific target profile.

In an implementation, the invention is a method including providing anumber of policies applicable to a number of targets, each target havinga set of capabilities, where a policy includes an expression and anevent; determining whether a policy is relevant or irrelevant to aspecific target; and transferring relevant policies to the specifictarget and not transferring irrelevant policies to the specific target.Relevant policies may be evaluated at the target.

In a further aspect of deployment, policies are deployed to targets andtargets can evaluate the policies whether they are connected ordisconnected to the system. The policies may be transferred to thetarget, which may be a device or user. Relevant policies may betransferred while not relevant policies are not. The policies may havepolicy abstractions.

In an implementation, the invention includes a method of operating aninformation management system including providing a device having adecision engine to manage information accessible via the deviceaccording to a first set of policies stored on the device; connecting ofthe device to a network with a server having access to a central policydatabase; and via the server, sending the device a second set ofpolicies to replace the first set of policies. The method includes afterreceiving the second set of policies at the device, using the decisionengine to manage information accessible via the device according to thesecond set of policies, whether the device is connected or disconnectedfrom the network.

In an implementation, the invention includes a method of operating aninformation management system including providing a device having adecision engine to manage information accessible via the deviceaccording to a first set of policies stored on the device; connecting ofthe device to a network with a server having access to a central policydatabase; and via the server, sending the device a second set ofpolicies. The method includes after receiving the second set of policiesat the device, using the decision engine to manage informationaccessible via the device according to a combination of the first andsecond set of policies, whether the device is connected or disconnectedfrom the network.

In an implementation, the invention includes a method of operating aninformation management system including providing a device having adecision engine to manage information accessible via the deviceaccording to a first set of policies stored on the device; connecting ofthe device to a network with a server having access to a central policydatabase; and via the server, sending the device a set of policyalterations. The method includes on the device, altering the first setof policies based on the set of policy alterations to obtain a secondset of policies; and after altering the first set of policies, using thedecision engine to manage information accessible via the deviceaccording to the second set of policies, whether the device is connectedor disconnected from the network.

In an implementation, the invention includes a method of managinginformation of a network including providing a server handling a firstpolicy language having access to a policy database; providing a firstdevice having a decision engine to manage information accessible via thedevice according to a first set of policies stored on the device, wherethe first set of policies is associated with the first policy language;and providing a second device that handles a second policy language. Themethod includes translating a first policy of the policy database intothe second policy language and transferring the first policy in thesecond policy language to the second device.

In an implementation, the invention includes a method of managinginformation of a network including providing a number of rules, where arule includes an expression; providing a device having a target profile;and determining a subset of the rules relevant to the target profile,where the target profile indicates applications available on the device.The method includes transferring the subset of rules to the devicehaving the target profile and controlling access to the informationbased on the subset of rules.

In an implementation, the invention includes a method of managinginformation of a network including providing a number of policies on aserver; selecting a subset of policies of the server to transfer to adevice based on attributes associated with the device; transferring thesubset of policies to the device; and controlling access of informationby the device using the subset of policies.

In an implementation, the invention includes a method includingproviding a first policy having an expression where an evaluation of theexpression requires information provided by a first device of a network.When a second device is connected to a network, the first policy isdeployed on the second device by altering the first policy to obtain asecond policy by removing a reference in the expression to theinformation provided by the first device of the network; andtransferring the second policy to the second device. The method includesenforcing the second policy on the second device, where enforcement ofthe second policy does not request information from the first device.

In an implementation, the invention includes a method includingproviding a first policy having an expression where an evaluation of theexpression requires information provided by a first device of a network.When a user logs onto a second device, which is connected to a network,the first policy is deployed on the second device by altering the firstpolicy to obtain a second policy by removing a reference in theexpression to the information provided by the first device of thenetwork; and transferring the second policy to the second device. Themethod includes enforcing the second policy on the second device, whereenforcement of the second policy does not request information from thefirst device.

FIG. 23 shows an example of late policy binding which occurs when a user2103 logs on to a client workstation 2101. The policy enforcer 2102 onthe client workstation requests for policies relevant to the user. Belowis a policy that successfully binds to the user based on a targetprofile provided by the policy enforcer. This example also illustratesthe function of a “pull” mode of policy distribution.

FOR document.name = “file://server1/**” OR document.name =“file://server2/finance/**” OR document.name =“http://staff.company.com/marketing/**” OR document = Sensitive ON OPENBY user <> Managers AND user <> Executives DO DENY

The simplified system described in this example includes a clientworkstation 2101 which has a policy enforcer installed 2102, a policyserver 2104, and a policy repository 2105. In step 1 (2106), a user whois a general administration staff 2103 logs on to the clientworkstation. The policy enforcer on the client workstation interceptsthe log on operation and contacts the policy server in a step 2 (2107)to obtain a set of policies relevant to the user or obtain a policyupdate. In the process, the policy enforcer provides the policy serverwith a target profile which includes information about the workstationand the user such as login name or SID on a Windows client.

The policy server receives the request initiated by the policy enforceron the client workstation in a step 3 (2108) along with the targetprofile. The policy server processes the request by selecting relevantpolicies from the policy repository. The selection process results in asubset of policies matching the target profile which may include zero,one, or more than one policy. This selection process is called policybinding. The resulting subset of policies and related supportinformation together is called a policy bundle.

During the binding process, a policy server can make intelligentdecision on whether a policy is relevant to a target based on ananalysis of different elements in a policy combined with informationabout the target. For example, the binding process may identify a policyapplies to file access based on information specified in the policy'sresource element. At the same time, the target profile indicates thatthe target can only handle e-mail messages and calendar functions butnot file access. The binding process decides that such policy is notrelevant to the target. In addition, the binding process can also usedeployment directives entered by a policy author to determine if thepolicy relevant to the target.

This example assumes that the binding process resulted in the selectionof the above policy because the target profile specifies a user (e.g.,“mjohnson”) who is neither in Managers nor Executives user groups, andmatching the subject element (or BY element) of the above policy. Thepositive consequence of the policy suggests a blocking action making ita useful policy. In this case, the policy bundle created by the policybinding process includes the above policy and information relevant tothat policy.

In a specific implementation where a management system supports policyabstraction, the policy binding process includes selection of policyabstractions associated with the selected policies and policyabstractions matching the target profile along with other policyabstractions being referenced and policies reference any selected policyabstractions. In this case, the policy abstraction “Sensitive” isincluded. Depending on the definitions of policy abstractions “Managers”and “Executives” and optimization techniques applied at the policyserver, the policy abstractions “Managers” and “Executives” may beincluded. The binding process may also produce additional informationrelevant to support evaluation of the selected policies and policyabstractions. In this case, the policy bundle created by the policybinding process includes a subset of policies, a subset of policyabstractions and all relevant information.

If a policy bundle is produced in step 3, the policy server returns apolicy bundle to the client workstation in a step 4 (2109) along withany additional support information.

In a specific implementation, the policy server performs optimization onpolicies and policy abstractions produced by the policy binding processand transfer the optimized subset of policies and policy abstractions ina policy bundle to the client workstation.

In a specific implementation, the policy server compiles a list ofdifferences between the subset of policies and policy abstractionsproduced in the policy binding process and the subset of policies andpolicy abstractions on the client workstation and transmits the list ofdifferences and other supporting information in a policy bundle to theclient workstation.

The client workstation receives a response from the policy server in astep 5 (2110). If the policy binding process in step 3 produces a policybundle, the responses contains a policy bundle. The subset of policiesin the policy bundle is enforced at the client workstation.

In a specific implementation, the policy bundle received by the clientworkstation replaces the subset of policies or policy abstraction, orboth, on the workstation.

In a specific implementation where multiple subsets of policies orpolicy abstractions, or both, are supported by a client workstationpolicy enforcer, the policy bundle received may replace one subset ofpolicies or policy abstractions, or both, on the client workstation orcombine with at least one subset of existing policies or policyabstractions, or both, on a workstation.

In a specific implementation where a client workstation policy enforcersupports transferring a list of differences in a policy bundle, theclient workstation policy enforcer applies the list of differences inthe policy bundle received to an existing subset of policies or policyabstractions, or both, to reconstruct the desire subset of policies orpolicy abstractions, or both.

For ease of explanation, the followings are not shown in the aboveexample: (1) policies not bound to the user or the client workstation,or both; (2) other policies (in additional to the one shown above) thatbind to the user or the client workstation, or both; (3) policyabstractions associated with the above policy and other policies boundto the user or the client workstation, or both; and (4) policyabstractions not bound to the user or the client workstation, or both.

FIG. 24 shows an example of late policy binding which occurs when apolicy server 2201 initiates transfer of policies to a clientworkstation 2203 and a document server 2205. Below are three policieswhere policy 1 and policy 2 are bound to the client workstation andpolicy 3 is bound to the document server. This example also illustrates“push” mode of policy distribution.

# {POLICY 1} FOR document.name = “file://server1/merger-docs/**” ON OPENBY user <> Executives DO DENY # {POLICY 2} FOR document = ConfidentialON COPY WHERE device.type = “workstation” ANDdestination.device.category = “portable” DO DENY AND LOG OTHERS ALLOW #{POLICY 3} [[EXCHANGE-SERVER]] FOR message = Confidential ANDmessage.recipient = NOT Employees ON SEND BY user = Employees DO ALLOWAND ENCRYPT OTHERS ALLOW # {POLICY ABSTRACTION 1} Executives = <map toLDAP group “executive”> # {POLICY ABSTRACTION 2} Confidential :=document.name = “file://project-server/unrelease/**” OR document.name =“*-contract.doc” OR document.properties.category = “Confidential” ORmessage.subject CONTAINS “Confidential” # {POLICY ABSTRACTION 3}Employees = <map to LDAP group “complete-hr-list”>

The simplified system described in this example includes a policy server2201, a policy repository 2202, a client workstation 2203 which has apolicy enforcer installed 2204, a document server 2205 which has aMicrosoft Exchange Server installed, and a policy enforcer 2207installed on the document server. In a step 1 (2208), a policyadministrator publishes the three policies illustrated above forimmediate deployment. The policy server executes its “push” mode policydeployment process. The push mode deployment process requires that thepolicy server contacts all relevant policy enforcers, and for eachpolicy enforcer, deliver one or more of the above three policies whichare relevant to the target that the policy enforcer manages. The policyserver looks up information regarding active policy enforcers andlocated the client workstation and the document server and theirrespective target profiles.

In a specific implementation, the policy server stores active targetprofiles in a local database and retrieves the target profiles from thelocal database to enable late binding of policies or policyabstractions, or both, to carry out push mode policy distribution.

In a specific implementation, the policy server makes a request to eachpolicy enforcer to acquire a current target profile to facilitate latebinding of policies for a push mode policy distribution.

In a specific implementation, the policy server broadcast a message toall active policy enforcers instructing each policy enforcers toinitiate a pull mode policy update process.

The policy server processes a target profile associated with the clientworkstation. In doing so, the policy server's policy binding processbound policy 1 and policy 2 to the client workstation.

For policy 1, the policy binding process determined that the resourceelement refers to file objects and subject element refers to user whoseis not in Executives group. The target profile either explicitlyindicates that the client workstation is capable of handling fileobjects, or the policy binding process deduces from the clientworkstation being a workstation which should have file handlecapability. The target profile also indicates there is an active user onthe client workstation. Based on the information available, the policybinding process determines that policy 1 is relevant to the clientworkstation.

For policy 2, the policy binding process identified form the resourceelement that the policy applies to documents and from the contextelement that the policy should apply to a workstation. Based on thisinformation, the policy binding process determines that the policy isrelevant to the client workstation.

After policy binding process determines policy 1 and policy 2 arerelevant to the client workstation, it finds all policy abstractionsreferenced by the two policies. In this case, the policy abstractionsare “Executives” and “Confidential.” The two policies and two policyabstractions are places in a policy bundle. If there is any additionalconfiguration information these policies or policy abstractions dependon, they are also added to the policy bundle.

The policy binding process discussed above performs inspection onpolicies and then locates policy abstractions being references. In apolicy server that supports policy abstraction, it is also necessary toperforms inspection on policy abstractions and then locate associatepolicies. This bottom up technique requires policy abstractions beinspected before policies so that a relevant policy based entirely onpolicy abstraction can be successfully identified.

In a specific implementation, a system of the invention supportspolicies and policy abstractions but not dynamic distribution of policyabstractions (i.e., dynamically distribute policies only). The policybinding process inspects policies for its relevancy to a target. Allrelevant polices are placed in a policy bundle along with anyinformation required to support evaluation of the selected policies andpolicy abstractions.

In a specific implementation, a system of the invention supportspolicies and policy abstractions but not dynamic distribution ofpolicies (i.e., dynamically distribute policy abstractions only). Thepolicy binding process inspects policy abstractions for its relevancy toa target. All relevant policy abstractions are placed in a policy bundlealong with any information required to support evaluation of policies atthe target using the selected policy abstractions.

In a specific implementation, a system of the invention supportspolicies and policy abstractions but not dynamic distribution ofpolicies (i.e., dynamically distribute policy abstraction only). Thepolicy binding process inspects policy abstractions for its relevancy toa target. The policy binding process may also inspect policies eventhough they are not being distributed to the target for relevancy. Inaddition, the relevant policies and policy abstractions can be crossreferenced to further eliminate irrelevant policies and policyabstractions. At the end, only policy abstractions referenced byrelevant policies are considered for distribution, and these policyabstractions will be referred to as truly relevant policy abstractions.All truly relevant policy abstractions are placed in a policy bundlealong with any information required to support evaluation of policies atthe target using the truly relevant policy abstractions.

In a step 2 (2209), the policy server transfers the policy bundle to theclient workstation.

In a specific implementation, a policy server performs optimization onthe policies, or policy abstractions, or both, in the policy bundle andtransfers the optimized policies, or policy abstractions, or both, in apolicy bundle along with all supporting information to the clientworkstation. The optimized policies and policy abstractions may have thesame policies format as the preoptimized policies or may be transformedto a different policy format.

In a specific implementation, a policy server compiles a list ofdifferences between the policies, or policy abstractions, or both, inthe policy bundle and the policies, policy abstractions, or both, on theclient workstation. The list of differences along with all supportinginformation are placed in a policy bundle and transferred to the clientworkstation.

The client workstation receives the policy bundle from the policy serverin step 3 (2210). The subset of policies, or policy abstractions, orboth, in the policy bundle is enforced at the client workstation.

In a specific implementation, the policy bundle received by the clientworkstation replaces the subset of policies or policy abstraction, orboth, on the workstation.

In a specific implementation where multiple subsets of policies orpolicy abstractions, or both, are supported by a client workstationpolicy enforcer, the policy bundle received replaces at least one subsetof policies or policy abstractions, or both, on the client workstationor combine with at least one subset of existing policies or policyabstractions, or both, on a workstation.

In a specific implementation where a client workstation policy enforcersupports transferring a list of differences in a policy bundle, theclient workstation policy enforcer applies the list of differences inthe policy bundle received to at least one subset of existing policiesor policy abstractions, or both, to reconstruct the desired at least onesubset of policies or policy abstractions, or both.

The policy server repeats the above policy binding and transferprocesses on a target profile associated with the document server(including all implementation specific steps). Since the document serverhas a Microsoft Exchange Server installed, information related toMicrosoft Exchange Server is provided in the target profile. Using suchinformation, the binding process identifies that policy 3 is relevant tothe target. Specifically, policy 3 contains a deployment directive“EXCHANGE-SERVER” specifying it should be deploy to all targets runningMicrosoft Exchange Server.

In a step 4 (2211), a policy bundle constructed in the policy bindingstep is transferred to the document server. Step 4 may also includeimplementation specific optimization and other transformation stepsdescribed under step 2.

The document server receives the policy bundle from the policy server ina step 5 (2212). The subset of policies, or policy abstractions, orboth, in the policy bundle is enforced at the client workstation. Step 5may also include implementation specific processing steps describedunder step 3.

This description of the invention has been presented for the purposes ofillustration and description. It is not intended to be exhaustive or tolimit the invention to the precise form described, and manymodifications and variations are possible in light of the teachingabove. The embodiments were chosen and described in order to bestexplain the principles of the invention and its practical applications.This description will enable others skilled in the art to best utilizeand practice the invention in various embodiments and with variousmodifications as are suited to a particular use. The scope of theinvention is defined by the following claims.

The invention claimed is:
 1. A method of managing informationcomprising: providing a plurality of policies stored at a server,wherein a first policy comprises a first conditional statementcomprising a first variable defined by a first abstraction and a firstcorresponding action that will be performed when the first conditionalstatement is satisfied, the first abstraction comprises a definitionstatement stored separately from the first policy; determining a subsetof the plurality of policies relevant to a target; transferring thesubset of the plurality of policies comprising the first conditionalstatement comprising the first variable at the target, wherein thesubset of the plurality of policies is stored at the target; andallowing the target to control access to the information based on thesubset of the plurality of policies stored at the target.
 2. The methodof claim 1 wherein the information, for which the target controlsaccess, is stored at the server.
 3. The method of claim 1 wherein theinformation, for which the target controls access, is stored at thetarget device.
 4. The method of claim 1 wherein the definition statementassociated with the first variable is not transferred and stored at thetarget.
 5. The method of claim 1 wherein the target comprises a device.6. The method of claim 1 wherein the target is a computer, and thecomputer comprises executable code controlling access to the informationbased on the subset of policies.
 7. The method of claim 1 wherein thefirst variable comprises a resource, and the resource comprises at leastone of a file, an e-mail message, a Web page, a file system object, aportlet, a range of cells on a spreadsheet, a named region in adocument, or an application data object.
 8. A method of managinginformation comprising: providing a plurality of policies stored at aserver, wherein a first policy comprises a first conditional statementcomprising a first variable defined by a first abstraction and a firstcorresponding action that will be performed when the first conditionalstatement is satisfied, and the first abstraction comprises a definitionstatement stored separately from the first policy; transferring at leastone of the plurality of policies to a target; and allowing the target tocontrol application usage based on the plurality of policies transferredto the target, wherein application is resident at the target.
 9. Themethod of claim 8 wherein the target is a computer, and the computercomprises executable code controlling application usage.
 10. The methodof claim 8 wherein the at least one of the plurality of policiestransferred to a target is stored at the target.
 11. The method of claim8 wherein the application, for which the target controls usage, is aword processing program.
 12. The method of claim 8 wherein theapplication, for which the target controls usage, is a spreadsheetprogram.
 13. The method of claim 8 wherein the application, for whichthe target controls usage, is an e-mail program.
 14. The method of claim8 wherein the application, for which the target controls usage, is a Webbrowser program.
 15. An information management system comprising: aplurality of rule components and a plurality of abstraction components,wherein a rule component comprises an expression having a variable, andthe variable is defined in an abstraction component; a policy servercomponent, accessing the rule and abstraction components; a targetdevice component, coupled through a network connection to the policyserver component, the target device comprising a code component, whereinthe rule and abstraction components stored remotely from the targetdevice component are stored separately; a deployment mode of operationin which the policy server determines a subset of rule and abstractioncomponents are relevant to the target device component and transfersthis subset of rule and abstraction components to the target devicecomponent via the network connection; and an execution mode of operationin which the code component of the target device manages access toinformation based on the subset of rule and abstraction components. 16.The system of claim 15 wherein the subset of rule and abstractioncomponents is stored at the target device.
 17. The system of claim 15wherein the information, for which the target device manages access to,is stored at a server that is remote from the target device.
 18. Thesystem of claim 15 wherein the information, for which the target devicemanages access to, is stored at a target device.
 19. An informationmanagement system comprising: a plurality of rule components and aplurality of abstraction components, wherein a rule component comprisesan expression having a variable, and the variable is defined in anabstraction component; a policy server component, accessing the rule andabstraction components; a target device component, coupled through anetwork connection to the policy server component, the target devicecomprising a code component, wherein the rule and abstraction componentsstored remotely from the target device component are stored separately;a deployment mode of operation in which the policy server determines asubset of rule and abstraction components are relevant to the targetdevice component and transfers this set of rule and abstractioncomponents to the target device component via the network connection;and an execution mode of operation in which the code component of thetarget device manages application usage in the information managementsystem based on the subset of rule and abstraction components.
 20. Thesystem of claim 19 wherein the subset of rule and abstraction componentsis stored at the target device.